Configurations

These configurations play a vital role in ensuring that your platform is able to customize our payment flows as per your business needs.

Payment Status Values

We understand that keeping track of your payment status is important. To provide clarity, we've outlined the different levels of payment statuses and how they relate to each other.

Payment Status Hierarchy

Our system uses a hierarchical approach to track your payments, ensuring accurate and detailed information on the payment lifecycle. This hierarchy includes:

• Transaction Status: This represents the final status of your payment request.
• Transaction Attempt Status: This reflects the status of individual payment attempts made by the payer.
• Action Values: These indicate specific actions taken, on transaction attempt, by the:
  • Merchant regarding a "HOLD" attempt when Auto-Refund is Disabled.
  • Our System when Auto-Refund is Enabled.
    
    

Understanding Each Level

Transaction Status (The Big Picture)

This status provides the current status of your payment request. It answers the questions: "What is happening with my payment request and what is the final status in the end?"

Possible Transaction Statuses:

Transaction Attempt Status (The Details)

This status tracks individual attempts to process your payment. It answers the question: "How did each attempt to process my payment go?"

📘

Relationship to Transaction Status: A single transaction can have multiple attempts mapped against it. This means a "Transaction Status" can be linked to many "Transaction Attempt Statuses" irrespective of the active configurations. This is because the status mapping is driven solely by the number of payment attempts performed against a single payment request.

Possible Transaction Attempt Statuses:

Action Values (Managing Edge Cases)

These values are populated based on the payment scenario and the Auto-Refund configuration. They indicate the specific action taken, either by your platform or by our system, for a specific transaction attempt.

Possible Action Values:

How They Work Together

You want to collect a UPI payment from your customer (payer) . You initiate one of our collection APIs and receive the payment link in the response, which you then share with the customer.

• The "Transaction Status" starts as "PENDING."

• The first payment attempt might fail due to a technical issue or because the user entered the wrong MPIN.

  • We will mark this "Transaction Attempt" as "FAILED"

• If Auto-Retry is

  • Disabled, we mark the "Transaction Status" as "FAILED" and send the Transaction Status Callback to your platform.
  • Enabled, the payer can initiate another payment via the same shortlink and the "Transaction Status" remains as "PENDING"

• The second "Transaction Attempt" is successfully completed by the customer!

  • We will mark this "Transaction Attempt" as "SUCCESS".
  • Finally, the "Transaction Status" will be updated to "SUCCESS" and we will send the Transaction Status Callback to your platform.

• However, if a payment comes in after the payment link had expired and:

  • Auto-refund is _disabled _for your account, the "Transaction Attempt " will be marked as "HOLD"
    • Our system will alert you by sending a Transaction Status Callback where the transaction_attempt_status value will be "HOLD"
    • You can then choose to "Release" or "Capture" the funds.
    • Based on the action you choose, the action value will be "RELEASED" or "CAPTURED"
  • Auto-refund is _enabled _for your account, the "Transaction Attempt " will be marked as "SUCCESS"
    • Our system will update the action value to "AUTO_REFUNDED"

• As the final step, our system will send another Transaction Status Callback with the updated and terminal (final) values for the following parameters:

  • transaction_status
  • transaction_attempt_status
  • action

  Payment Scenarios

  This section explains how the payment status is updated, covering various scenarios you might encounter.

Common Scenarios

DEEMED and DISPUTED Transactions

Edge Cases

Refund Status Values

This status provides the current status of a refund request. It answers the question: "What is happening with my refund request?"

📘

Please Note

• A refund request can be initiated at a Transaction or a Transaction Attempt level via the Issue Refund API.
• Refunds can only be initiated when the status value, for a given Transactions or Transaction Attempt, is "SUCCESS".
• We refer to the successful payment, by the end customer, as the 'Credit Transaction'. The refund is referred to as the 'Debit Transaction'.
• We do not update the status of the payment request (credit transaction) when the refund is requested.
• You may query the status of the refund via the Get Transaction Status (Basic and Advance) API.
  • If you initiate the GTS Advance) API with the details of the credit transaction, the API response will contain the details of the associated refund (debit) transactions.
• If a Transaction Attempt was "AUTO REFUNDED" or "RELEASED" (corresponding action value), the Issue Refund API will throw an error if the merchant tries to initiate a refund.

Key Takeaways

• Clarity and Transparency: This hierarchical system provides a clear and detailed view of your payment journey.
• Many-to-One Relationship: Multiple "Transaction Attempt Statuses" can contribute to a single "Transaction Status".
• HOLD and Actions: "Action Values" are only relevant when managing edge cases and will vary depending on the level of control you want to maintain.
• Separation of Credit and Debit Transaction Status: We do not update the status of the payment request (credit transaction) when the refund is requested. The refunds (debits) are mapped against each successful (credit) transaction attempt.
• If the funds against a transaction attempt (and subsequently a transaction request) are settled or refunded, the terminal status will always be "SUCCESS".
  • This applies for all transaction attempts which are "RELEASED" or "AUTO_REFUNDED" (action values) as well.