This policy establishes the requirements for cancellation, refunds, failed transactions, duplicate transactions, pending transactions and payment disputes for transactions initiated through Aatman and processed through the AurusPaytech payment platform. It defines responsibilities between Aatman, AurusPaytech, merchants/service providers, banks, payment networks and customers, and establishes controlled timelines, approvals, reconciliation and audit trails.
This policy applies to payment transactions facilitated through Aatman where AurusPaytech provides payment processing, payment aggregation/payment gateway or related payment technology services. It covers card, UPI, net banking and other payment methods supported by the applicable payment integration, subject to the rules of the relevant payment network, bank, issuer/acquirer and applicable law.
| Party | Primary Responsibility | Key Controls |
|---|---|---|
| Merchant-facing business (Aatman) | Owns merchant relationship terms, customer-facing product/service cancellation policies, and commercial refund determinations (unless contractually reassigned). |
|
| Payment Aggregator (PA) (AurusPaytech) | Processes authorized refund instructions, transaction status checks, reversals and payment dispute/chargeback workflows within its role. |
|
|
Acquirer / Bank / Network (Acquirer / Issuer Bank / NPCI / Card Networks) |
Executes or facilitates settlement, reversal/refund and dispute processes according to applicable network/bank rules. | Interbank Settlement, refund posting, chargeback/dispute processing and status responses. |
|
Consumer Application Provider (TPAP / PSP App) |
Provides consumer-facing payment interfaces (e.g., UPI TPAP apps) to scan QR codes, initiate authorization flows, and display transaction results. |
|
|
End User (Customer / Payer) |
Originates genuine payment instructions, provides accurate transaction metadata, and files disputes or claims through authorized bank/app channels. |
|
A refund may be initiated where:
Refund eligibility does not override applicable fraud, AML, sanctions, regulatory, contractual or payment-network controls.
Cancellation shall be governed primarily by Aatman’s published commercial/service terms. Aatman may permit cancellation before service fulfillment, subject to the applicable service-specific conditions. After fulfillment or where cancellation is restricted by the applicable terms, a refund may be declined unless required by law, contract, regulatory/payment-network rules or an approved exception.
AurusPaytech does not independently determine Aatman’s commercial cancellation policy unless expressly agreed in the applicable contract.
Unless a shorter contractual or regulatory timeline applies, Aatman should acknowledge a valid refund request within 2 business days and process an approved refund instruction without undue delay. The time taken for the amount to appear in the customer’s account may depend on the issuer bank, acquirer, card network, UPI/banking channel or other payment method.
For failed transactions covered by RBI’s prescribed TAT framework, the applicable RBI auto-reversal and compensation requirements shall be followed. The prescribed TAT is an outer limit and applicable compensation for delay shall be handled as required by RBI rules.
Where the payment method/network imposes a specific refund window or operational requirement, the applicable network/bank rule shall be followed.
A failed transaction is one that is not fully completed due to circumstances such as communication failure, timeout or other causes not attributable to the customer, subject to the applicable RBI/payment-system definition.
Duplicate transactions include two or more successful debits for the same order/service where only one payment was intended, or duplicate payment instructions caused by retry, timeout or integration behaviour.
All duplicate cases shall be recorded for reconciliation and recurring root-cause analysis.
A transaction shall be treated as pending when the final success/failure outcome is not yet confirmed by the relevant payment channel.
Full refunds return the complete eligible transaction amount. Partial refunds return only the approved portion of the transaction. Partial refunds shall be permitted only where supported by the applicable payment channel and Aatman’s commercial terms.
Refund API credentials, keys, authentication data and payment information shall be protected in accordance with AurusPaytech security controls and applicable PCI DSS requirements.
Payment disputes and chargebacks shall be managed through the applicable acquiring bank, payment network and AurusPaytech dispute process. A chargeback is distinct from a voluntary merchant refund and shall not be treated as a normal refund request.
Aatman and AurusPaytech shall maintain appropriate records of original transactions, refund requests, approvals, refund references, reversals, chargebacks, communications, settlement/reconciliation entries and exception handling.
Records shall be retained for the period prescribed by applicable law, RBI requirements, contractual obligations, payment-network rules and the organization's record-retention policy, whichever applicable requirement is longer.
Refunds may be placed on hold for investigation where there are reasonable indicators of fraud, account takeover, refund abuse, money laundering, sanctions concerns or other prohibited activity. Any such investigation shall be handled under the applicable fraud/risk/ AML procedure and shall not be used to circumvent mandatory regulatory timelines.
Aatman shall provide a clearly accessible customer support/grievance channel for refund and cancellation requests. AurusPaytech shall provide the applicable operational escalation mechanism for payment-processing issues. Complaints shall be logged, assigned, tracked and closed within applicable regulatory and internal timelines. The applicable nodal/grievance officer details and escalation matrix shall be published where required.
This policy shall be implemented with reference to applicable RBI directions governing Payment Aggregators, the RBI framework for failed transactions and customer compensation, applicable payment-network operating regulations, contractual requirements, consumer-protection requirements, PCI DSS/security requirements and other applicable laws and regulations, as amended from time to time.
Where a regulatory, statutory, payment-network or contractual requirement prescribes a stricter timeline or control than this policy, the stricter applicable requirement shall prevail.
| Area | Aatman Control | AurusPaytech Control | Evidence |
|---|---|---|---|
| Refund approval | Validate eligibility and approve | Validate transaction/platform eligibility and process | Request, approval, transaction/refund ID |
| Failed transaction | Customer communication and case tracking | Status monitoring, reversal/escalation | Gateway status, reversal reference |
| Duplicate transaction | Confirm order duplication | Idempotency/duplicate detection | Transaction/order IDs |
| Pending transaction | Do not fulfil/refund solely on debit message | Status polling/reconciliation | Status logs |
| Partial refund | Approve amount per terms | Enforce cumulative refund limit | Refund records |
| Chargeback | Provide fulfilment/refund evidence | Manage payment-channel workflow | Representment/chargeback evidence |
| Reconciliation | Reconcile order/refund records | Reconcile gateway/acquirer/settlement | Daily reconciliation reports |
Any exception to this policy shall be documented with business justification, risk assessment, approval by the designated authority and an expiry/review date. Exceptions shall not override mandatory RBI, statutory or payment-network requirements.