Payment route
Translate every provider event into a clear customer state.
The payment interface, provider account, transaction callback, customer language, order record, fulfilment team, refund route, and finance reconciliation must agree. A Malaysia-facing checkout is a service blueprint, not a button.
| Service layer | Decision to make | Failure to test |
|---|---|---|
| Offer | Approved description, currency display, total, terms, customer details, timing, and support expectations. | Changed price, unavailable item, expired quote, incomplete customer record. |
| Provider | Supported merchant account, country/currency combination, authentication, callback, settlement, and restrictions. | Timeout, duplicate request, delayed result, abandoned session, provider outage. |
| Customer message | Language, confirmation, pending state, decline, retry, receipt or invoice route, and next step. | Payment succeeds but page fails; page succeeds but provider record differs. |
| Fulfilment | Which accepted state starts work, who can override it, and how partial delivery or cancellation behaves. | Duplicate fulfilment, missing confirmation, changed order, manual adjustment. |
| Closeout | Refund, dispute, support, fees, settlement, reconciliation, tax review, and evidence retention. | Provider and internal records do not match at the end of the period. |
Responsibility split
Engineering preserves approved truth.
- Client confirms merchant identity and provider access
- Qualified owners decide tax, invoice, consumer, and disclosure duties
- Language reviewer accepts all customer-facing transaction states
- Support team owns recovery, refund, and dispute communication
- Finance owner accepts the reconciliation evidence
Map the route