How payments work

Your server ──(1) POST /api/payment-process──► Gateway ──► card processor
     ▲                                             │
     │◄──(2) immediate answer (APPROVED / DECLINED / ERROR / IN PROGRESS)
     │◄──(3) postback to your postbackUrl when the final result is known
     └──(4) POST /payment-Lookup any time
     └──(5) POST /payment-refund for an APPROVED payment

1. You create a payment. The gateway checks your key, the MID and the ban list, stores the payment as pending and sends it to the MID’s processor.
2. If the processor decides at once, the response carries the final status.
3. If the shopper must authenticate, the response is IN PROGRESS with a redirectUrl.
4. When the final status is known the gateway sends a postback to your postbackUrl.
5. You can read the payment at any time with a lookup.

Two ways to take the card

	Server-to-server	Hosted checkout
Who handles the card number	Your server sends it to the gateway	The shopper types it into a gateway page inside your site
You call	POST /api/payment-process	POST /api/payment-session, then mount the widget
PCI scope	Larger: card data crosses your server	Smaller: it never reaches you
Guide	Create a payment	Hosted checkout

After either, the result reaches you the same way: a postback and a lookup.

Statuses you will see

Where	Values
Create-payment response	APPROVED, DECLINED, ERROR, IN PROGRESS
Lookup response	APPROVED, DECLINED, ERROR, PENDING
Postback	APPROVED, DECLINED, ERROR, PENDING

The same in-flight state is called IN PROGRESS in the create response and PENDING elsewhere. A refunded or charged-back payment still reports APPROVED; a refund is its own record with type REFUND, and a chargeback appears as a record with type CHARGEBACK.

A PENDING payment is not a failure. Never cancel the order or let the shopper pay twice because of it: wait for the postback or look it up.

Conventions

• JSON, camelCase field names. Amounts are decimal strings ("10.00").
• Your referenceCode (8 to 30 characters) must be unique across the platform. Reusing one is refused, so a retried request never creates a second payment.
• Errors share one shape. See Errors.