APM Payment Workflow
Follow alternative payment methods from customer action or provider confirmation through success, denial, cancellation, or expiration.
On this page
Alternative payment methods (APMs) can require a redirect, app switch, QR code, voucher, bank approval, or delayed provider confirmation. Read the current value from payment.data.status; if the payment is inside an order response, read order.payment.data.status.
Use this page for the APM-specific path. For every status definition and allowed direct transition, see Payment workflow and statuses.
Standard APM flow#
Most APMs start at pending. Some confirm immediately; others remain pending while the customer acts, then expose processing while DEUNA waits for provider confirmation.
| State | Meaning | Merchant action |
|---|---|---|
pending | Customer action, routing, or provider confirmation is still outstanding. | Present next_action or the method instructions and keep fulfillment blocked. |
processing | The method is waiting for an asynchronous provider result. | Wait for or retrieve the authoritative payment; do not retry prematurely. |
processed | The APM payment completed. | Apply the fulfillment policy and retain the provider references. |
denied | The current attempt was unsuccessful. | Do not fulfill; preserve the reason and evaluate whether a new attempt is allowed. |
cancelled | The method or merchant cancelled the payment. | Check whether prior funds require a refund or void before closing the order. |
expired | The allowed completion window closed. | Record terminal completion and create a new payment for another customer attempt. |
Customer action and return URLs#
Follow the method-specific next_action supplied by DEUNA. A browser return, app return, or customer-visible success page does not prove that money moved. Confirm payment.data.status after DEUNA receives and processes the provider result.
If the customer abandons the redirect or closes the browser, keep the payment unresolved until DEUNA reports an outcome. Do not synthesize denied, cancelled, or expired from front-end behavior.
Completion windows#
The time allowed to complete a payment is method- and configuration-specific. Voucher expiration, QR validity, bank-session timeouts, and provider processing windows are not interchangeable.
Do not calculate the final payment status from browser time or a local timer. Keep fulfillment blocked and wait until DEUNA reports processed, denied, cancelled, or expired. If your customer experience displays a countdown, treat it as presentation guidance unless the method contract explicitly makes it authoritative.
Authorization-capable APMs#
Some APM connections support authorization and capture. Those methods can expose authorizing, authorized, capturing, captured, or the partial-capture states instead of the standard purchase-only path.
When an APM uses authorization, follow the card workflow capture and void guidance for the shared payment statuses, but confirm method and processor support with your DEUNA Technical Account Manager (TAM). Do not infer capture or void support from the presence of a status in the global state machine.
Cancellation and refunds#
cancelled is not necessarily the last financial state. If collected funds existed, the payment can continue to refunded; if an authorization existed, it can continue to voided.
After a successful processed payment, refunds can move through partial_refunding, partial_refunded, refunding, and refunded when the APM connection supports them. See MPR — Multiple Partial Refunds for supported modes, time limits, concurrency, and remaining-balance behavior.
Integration checklist#
- Keep fulfillment blocked while the payment is
pendingorprocessing. - Follow the returned next action without treating the customer return as payment confirmation.
- Store provider references and confirmed amounts with each update.
- Handle delayed and repeated provider notifications idempotently.
- Retrieve the authoritative payment after a client timeout or missing return.
- Use the validated transition reference for retries, refunds, and reconciliation paths not shown in the normal flow.