Callback Identification

Exirom appends method identifiers to callback URLs. These identify card versus APM and the selected APM, but they do not distinguish payment from payout or refund. Keep the originating API flow in your callback route or transaction record.

#Identification Fields

#paymentMethod (Query Parameter)

All callbacks are sent as HTTP POST requests. Exirom appends paymentMethod to the callback URL regardless of the original callbackUrl provided.

#apmType (Query Parameter and Payload Field)

When paymentMethod=apm, apmType is appended to the URL and included in the payload body.

• Present only when paymentMethod=apm
• Value matches the Supported Payment Methods (PaymentMethod) enum
• Use it to select the APM-specific payload parser after resolving the originating flow

#Callback URL Examples

Given the original callback URL:

https://merchant.com/payment-status

Exirom invokes one of the following:

Card payment:

POST https://merchant.com/payment-status?paymentMethod=card

APM payment:

POST https://merchant.com/payment-status?paymentMethod=apm&apmType={APM_METHOD}

Example:

POST https://merchant.com/payment-status?paymentMethod=apm&apmType=UPI_QR

An APM payout receives the same paymentMethod=apm&apmType={APM_METHOD} query-parameter pattern. Use a dedicated callback URL, such as /callbacks/apm-payment versus /callbacks/apm-payout, or look up the transaction's originating flow before selecting its DTO and checksum formula.

#Parsing APM Callbacks (apmResponseData)

When paymentMethod=apm, the callback payload contains an apmResponseData field whose structure varies by apmType.

Do not assume apmResponseData has the same shape for all APMs. Always route parsing based on apmType.

Navigate to the relevant APM documentation page using the apmType value — each page describes the expected fields, redirect vs iframe behavior, and any required follow-up actions.

#Routing Summary

A single endpoint can handle all callbacks only if it also resolves the originating flow from merchant-owned routing or transaction state. paymentMethod and apmType alone are insufficient, especially for APM payment versus APM payout; those two callback types use different checksum formulas.

For card refunds, callback transactionId is the original card-payment ID, not refundId. Use the signed requestId to identify the individual refund and include it in the idempotency key.

#Related

• Payment Flow — apmResponseData schema and handling logic
• Webhook Best Practices — signature verification, deduplication, polling fallback