Card Payments
Take Visa and Mastercard payments with 3D Secure through NMB Bank's Mastercard gateway. The card is typed into gateway-hosted fields and never reaches your servers or Malipopay's. Create the payment with your apiToken, then let the hosted checkout, the embeddable card element or your own client run the session. On UAT the test gateway takes test cards and moves no money; on production every card payment is a real charge.
Create a card payment
Creates a card collection and returns its reference, for the embeddable card element, the hosted checkout link or your own client. Server side only, with your `apiToken` (the dashboard uses a `project` header plus a signed-in member's Bearer JWT; a bare `project` header is refused). Your project's limits apply as for any collection; the test-recipient whitelist does not, because a card payment has no phone number. Never send card numbers to Malipopay: `POST /api/v1/payment` refuses card fields with `CARD_DETAILS_NOT_ACCEPTED`.
Open a hosted card session
Creates a hosted session on the card gateway. Called from the payer's browser or app; no credential. The reference is required and must be a collection that can still be paid: a missing, unknown, deleted, cancelled, already paid or payout reference answers 400 and opens no session. The session is created on the project's own gateway account and on the right gateway (test for a test-mode project, live for a live one).
Bind a payment to the card session
Opens a new attempt (its own gateway order, `reference-Cn`) and writes the order, the amount read from the payment, the 3D Secure channel and the return URL onto the session. Returns what three-ds.js must be configured with. No credential; the amount is never taken from the caller unless card part payments are enabled.
Capture a card payment
Reads the attempt's authentication result from the gateway, decides, and issues the PAY. Called by the page when 3D Secure is not offered, and as a safety net after a challenge. Idempotent: a capture already credited answers alreadyPaid, and a second call while one is in flight answers PENDING. If the gateway does not answer the PAY, it answers PENDING with gatewayCode `UNCONFIRMED`: poll `GET /api/v1/payment/verify/{reference}`, which asks the gateway and settles it, and never start another attempt meanwhile. Always HTTP 200; branch on data.status.
D Secure return (gateway only)
The session's redirectResponseUrl. The card gateway sends the payer's browser here after the issuer challenge; you never call it. The outcome is read from the gateway, not from the form, and the answer is a 303: paid in full on a Malipopay page goes to the receipt `/r/slug`, a part payment to `/ref?reference`, and anything else back to the starting page with `?ref=&card=successful|declined|failed|pending&code=`.
D Secure return (gateway only, GET)
Same as the POST form. Some gateways and browsers return with GET.
Gateway notification (gateway only)
Where the card gateway reports every transaction result. You never call it and it is not your webhook: your integration hears about card payments through `payment.confirmed`. Reconciliation only: it never issues a PAY, and it credits an attempt only after reading the transaction back from the gateway and matching the attempt's amount.