Cross-border checkout looks simple to the buyer: choose a method, approve the amount, and receive confirmation. Behind that moment, the merchant must coordinate currency, payment routing, fraud controls, notifications, refunds, settlement, and reconciliation. Teams considering how customers pay with antom need to map that full lifecycle.
Antom offers hosted, embedded, SDK, and API-based paths across its payment products. The right path depends on development capacity, desired checkout control, customer devices, payment methods, and the operational detail the merchant can support after launch.
This guide turns the integration into a sequence of decisions that business, engineering, finance, risk, and support teams can review together.
Define the Payment Before Building It
Antom Dashboard provides 6 sandbox resources: API simulation, notification URL testing, error simulation, test cases, request logs, and notification logs. Use them against 1 defined buyer journey with a known entity, device, amount, currency, method, and settlement route.
- Draw the buyer, merchant front end, merchant server, Antom, and payment method.
- Mark every request, redirect, notification, inquiry, refund, and reporting event.
- Assign an owner and recovery action to every delayed or failed state.
Six Stages in an International Payment
The phrase pay with antom clearly covers 6 stages: account preparation, session creation, checkout presentation, buyer authorization, result confirmation, and settlement reconciliation. Each needs an owner and recoverable failure state.
Merchant Account Preparation
The merchant needs an approved account, product scope, client credentials, key configuration, and permitted methods. Availability may differ by acquiring region, business model, currency, and documentation, so sandbox access should mirror the intended production account.
Session or Payment Creation
Use 2 identifiers: the merchant payment or order ID and the Antom transaction ID. Idempotent server handling should ensure that 1 network retry does not create a second charge for the same order.
Checkout Presentation
A hosted page redirects the buyer to a provider-managed experience. Embedded components keep the flow inside the merchant page. API-only designs offer more control, while placing more interface logic, security work, and testing on the merchant.
Buyer Authorization
The buyer may approve a card, wallet, bank, QR, or app flow. Tests of how shoppers pay with antom should cover real device switching, cancellation, expiration, and interrupted customer returns.
Result Confirmation
Antom documents 2 independent result mechanisms: asynchronous notification and the inquiry API. A browser return is not proof of success; verify signatures, process repeated events idempotently, and inquire before creating another attempt when the outcome remains uncertain.
Settlement and Reconciliation
Authorization confirms the payment result, while settlement moves contracted funds to the merchant. Finance must connect transaction reports, currency conversion, fees, refunds, and settlement batches to internal orders before the process is considered operationally complete.
Two Integration Models to Compare
No single integration mode is best for every merchant. The tradeoff is usually speed and provider-managed presentation versus interface control and engineering responsibility. Compare the models against the same buyer journey and payment-method requirements.
Before selecting a mode, estimate implementation time, ongoing maintenance, security review, accessibility work, regional testing, and operational training. The lowest initial engineering effort may not remain the lowest-cost choice when market or product requirements become more complex.
Hosted or Prebuilt Checkout
Hosted checkout can reduce front-end work and speed an initial launch. The merchant still owns order creation, server authentication, result processing, customer communication, refund operations, and reconciliation. Branding and supported methods should be verified in the actual account.
Embedded or API-Led Checkout
Embedded components or API-only flows can offer tighter design control and deeper product integration. They require stronger engineering ownership for state management, validation, accessibility, device testing, error recovery, security boundaries, and changes introduced by individual payment methods.
Control the States That Create Loss
Most expensive incidents occur outside the happy path. A buyer retries, a page closes, a notification arrives late, or a refund fails. The launch plan should define a durable system of record and a safe action for every state.
Define which system may move an order from pending to paid, refunded, or canceled. Restrict manual overrides, log every change, and require a status inquiry when evidence conflicts. Clear authority prevents customer pressure from creating duplicate or unsupported actions.
Duplicate Attempts
Use stable merchant payment identifiers and idempotent server logic. Disable uncontrolled resubmission in the interface, but do not rely on the button alone. When status is uncertain, inquire before creating another payment request for the same order.
Delayed Notifications
Payment-method timeouts can range from 5 minutes for LinkAja to 14 minutes for many wallets and QRIS, 48 hours for several bank methods, and 7 days for cards or delayed paths. Monitoring and customer messages must follow the selected method.
| State | Customer Message | Merchant Action |
| Processing | 1 unresolved attempt | Inquire before retrying |
| Failed | 1 confirmed final failure | Offer 1 controlled retry |
| Succeeded | 1 final success event | Fulfill exactly once |
| Refunding | 1 refund request | Track to 1 final result |
Refund and Reversal Paths
Refund support, partial refund behavior, timing, and customer visibility can differ by payment method. Teams implementing pay with antom should test refunds in the sandbox or agreed test environment and map results into order, support, and finance systems.
Four Launch Tests That Matter
A production checklist should cover at least 4 test groups: device returns, currency and amount handling, risk and failure states, and reporting with support. One successful card transaction cannot prove the selected methods, refunds, notifications, or finance workflow.
Device and Return Testing
Run supported browsers, mobile web, application handoffs, redirects, and QR journeys. Close pages mid-flow and use back navigation. Confirm the merchant can recover state when the buyer returns through a different tab or the original session expires.
Currency and Amount Testing
Verify minor units, decimals, rounding, display currency, transaction currency, and contractual settlement currency. Test minimum and maximum amounts where applicable. A correct payment request can still create finance problems when systems disagree on units or conversion treatment.
Risk and Failure Testing
Use approved test cases for authentication, declines, blocked transactions, timeouts, and repeated calls. The risk team should confirm expected outcomes without treating a sandbox approval rate as a forecast of production performance.
Reporting and Support Testing
Download all 3 core financial reports—transaction details, settlement details, and settlement summary—and match them to internal orders. The summary is scheduled by 11:59 PM on the day after settlement, providing a concrete timing point for finance monitoring.
Make the Full Lifecycle Observable
International acceptance works when the buyer experience and the merchant's back office share a reliable payment state. Teams deciding how customers pay with antom should design notifications, inquiries, refunds, settlement, and reconciliation at the same time as checkout.
Launch one defined route, measure it, and expand after exceptions are understood. That discipline produces a payment system that can support new markets without turning every local method into a separate operational project.
