Client Requirement Understanding || Reward360

Index

1. Stakeholders & Status

2. Confidentiality Note

3. Introduction
   3.1 Problem Statement
   3.2 Solution Overview

4. IVR Payment Journey
   4.1 Customer Initiation
   4.2 Call Transfer to IVR
   4.3 Payment Processing via IVR
   4.4 Transaction Confirmation

5. Client Requirement Analysis
   5.1 Understanding
   5.2 Client's Expectations
   5.3 Phonon’s Role

6. Review of Shared BRD
   6.1 Key Identified Gaps

7. Customer Questionnaire & Presales Comments
   7.1 Who Receives the Funds?
   7.2 Supported Payment Gateways
   7.3 Fund Settlement Responsibility
   7.4 Merchant Account Creation
   7.5 Reconciliation Cycle
   7.6 Dispute & Chargeback Handling

8. Approach & Implementation Options
   8.1 Partnering with an Existing Payment Gateway
   8.2 Acting as a Payment Aggregator
   8.3 Bring-Your-Own-Gateway Model

1. Stakeholders & Status

2. Confidentiality Note

This document has been developed by Phonon.io for the sole and exclusive use of the customer / prospective customer with whom this document is being shared. Further, this document has been provided by Phonon.io to the recipient in good faith and based on a request from the recipient for the same. This document is a confidential document and contains confidential product technology, workflow, and commercial details that are for the sole usage of the intended recipients of this document. Recipients are advised not to share this document with any third party that is not the intended recipient of this document and neither to bring this document in full or parts into the public domain. Any unauthorized access may be brought to Phonon.io’s notice immediately. Phonon.io is free to take any legal action it deems necessary against any person or entity that violates this confidentiality agreement. Phonon.io is bound and governed by the rules of the state of Gujarat in India. In case you are not in agreement with the terms set in this clause or are not an intended recipient of this document, please destroy the document and intimate us of the same at responsibledisclosures@phonon.io

3. Introduction

3.1 Problem Statement

For international travel, 10-15% of merchants do not accept online payments, impacting customer experience.

3.2 Solution Overview

The IVR-based payment solution aims to bridge the gap in online payment acceptance for both international and domestic travellers. The payment process will be completed through Phonon IVR using DTMF inputs via debit/credit cards, ensuring a seamless and secure transaction experience.

4. IVR Payment Journey

4.1 Customer Initiation

• Customers connect with the call center agency for assistance.

• The call center agency guides the customer through the booking process, collecting all transaction details except sensitive card information (full card number, CVV, OTP).

4.2 Call Transfer to IVR

• The call center transfers the call to the Phonon IVR solution with all prerequisite details.

• Alternatively, IVR invokes the Reward 360 API to retrieve prerequisite details for processing payment over IVR.

• The customer is then connected to the IVR system to proceed with the transaction.

4.3 Payment Processing via IVR

• The IVR system prompts the customer to enter their card number and CVV securely.

• The IVR system invokes an API from Reward 360 to generate an OTP for authentication.

• The customer enters the OTP via DTMF input.

• The IVR system captures the OTP and invokes the Payment Gateway API (provided by Reward 360), sending all prerequisites along with the OTP for validation and transaction completion.

4.4 Transaction Confirmation

• Upon successful payment, the customer receives a transaction confirmation notification from the merchant.

5. Client Requirement Analysis

5.1 Understanding

• Phonon is not a payment gateway provider.

• Phonon's role is to design the IVR process, acting as a mediator between the call center agent, the customer, and the payment gateway.

5.2 Client's Expectations

• Define the payment settlement process.

• Ensure compliance with security regulations.

5.3 Phonon’s Role

• Implement IVR-based transaction processing.

• Coordinate with the payment gateway for seamless payments.

6. Review of Shared BRD

6.1 Key Identified Gaps

• Payment Settlement: The document does not specify who manages settlements and disbursals.

• Reconciliation & Reporting: Clarity needed on how transaction data will be reconciled and reported.

• Functional & Non-Functional Requirements: Specifics missing on security compliance, API response times, and transaction limits.

• Assumptions & Dependencies: Details on regulatory compliance (PCI-DSS, RBI norms) need to be confirmed.

• Dispute Resolution: No mention of chargeback handling and customer support in case of failed transactions.

7. Customer Questionnaire & Presales Comments

7.1 Who receives the funds on behalf of the merchants/service providers?

• They want to know if our CPaaS platform directly collects payments or if the funds go to the merchant's account via a third-party payment gateway.

  • Presales Comment:

    • We can integrate with an existing payment gateway where funds are transferred directly to the merchant.

    • If we want to be a payment aggregator, we will need to comply with financial regulations.

7.2 Which payment gateways you support?

• They are asking if we have existing integrations with gateways like Razorpay, PayU, Stripe, Paytm, etc.

  • Presales Comment:

    • Since we don’t currently have a payment gateway, we need to check whether to integrate with one (e.g., Razorpay, Stripe) or build your own API (which is complex and requires financial compliance).

7.3 Which party is liable to settle funds with the merchants?

• They want to know whether Phonon will handle fund settlements or if the payment gateway will.

  • Presales Comment:

    • If using a third-party gateway, settlements will be managed by the gateway.

    • If acting as an aggregator, we would be responsible for settlements, requiring financial compliance.

7.4 How are the merchant accounts created for settlement?

• They want to know if we will onboard merchants ourselves or rely on a payment gateway’s onboarding process.

  • Presales Comment:

    • If integrating with a gateway, merchants will be onboarded through that provider.

    • If acting as an aggregator, we need to implement a KYC and settlement process.

7.5 What is the reconciliation cycle?

• They are asking about the timeline and process for balancing transactions (daily, weekly, monthly).

  • Presales Comment:

    • If using a gateway, follow their cycle (usually T+1, T+2).

    • If managing payments, we will need a process to track and reconcile transactions.

7.6 How are disputes & chargebacks handled?

• They want to know how refunds, disputes, and chargebacks will be managed.

  • Presales Comment:

    • If integrating with a gateway, they usually have a dispute resolution system.

    • If we manage payments, we will need a team to handle disputes.

8. Approach & Implementation Options

8.1 Partnering with an Existing Payment Gateway

• Use APIs from established payment providers (Razorpay, PayU, Stripe, Paytm).

• Phonon acts as an integrator and does not hold funds.

• The payment gateway manages settlements, disputes, and compliance.

8.2 Acting as a Payment Aggregator (More Complex & Requires Compliance)

• Open an escrow account for fund settlements.

• Implement KYC for merchant onboarding.

• Obtain approval from banks or payment institutions.

• Build our own payment processing system.

8.3 Bring-Your-Own-Gateway Model

• Provide an IVR solution supporting multiple payment gateways via API.

• Customers integrate their preferred payment provider (Razorpay, Stripe, etc.).

Open