Key Requirements
Retrieve your API keys from your dashboard by following the steps on our
Authentication page. Use your public API key for
all card collection requests.
POST requests. See our Webhooks guide for setup instructions.
Supported currencies
Card collections are supported for both NGN and USD.For NGN cards, the
pin parameter is required in the Card Charge request.How card collections work
Card payments on Payaza can follow one of two flows depending on whether the card is enrolled in 3D Secure (3DS):Non-3DS flow (simple)
Non-3DS flow (simple)
- Your server calls Card Charge with the customer and card details. 2.
The response returns
do3dsAuth: falseandpaymentCompleted: true. 3. If acallback_urlwas provided, the customer is redirected to it with the final payment result in the POST body. 4. If nocallback_urlwas provided, handle the result in the same page via thewindow.messagepostMessageevent listener.
3DS flow (authentication required)
3DS flow (authentication required)
- (Optional) Call Check 3DS Availability upfront to determine if the card requires 3DS.
- Your server calls Card Charge with the customer and card details.
- The response returns
do3dsAuth: truealong withthreeDsUrl,formData, andthreeDsHtml. - Your frontend injects the
threeDsHtmlinto the DOM — this auto-submits a form inside an iframe that redirects the customer to the card issuer’s 3DS challenge page. - The customer completes the bank OTP or authentication challenge.
- If
callback_urlwas provided: the issuer redirects the customer back to yourcallback_urlvia aPOSTrequest containing the final payment result. - If no
callback_urlwas provided: the result is posted back to your page viawindow.postMessageand captured by awindow.addEventListener("message", ...)listener on the parent page.
Step 1 — Card Charge
Initiate a card payment. The response differs based on whether 3DS is required.transaction_reference has a recommended maximum length of 15
characters**.Response types
Card Charge returns one of three response shapes. Always checkdo3dsAuth first, then statusOk and paymentCompleted.
Response 1 — 3DS required
This is returned immediately from the Card Charge endpoint when the card requires 3DS authentication. The payment is not yet complete — you must render the threeDsHtml to proceed.
- With
callback_url: POSTed to yourcallback_urlafter 3DS completes, or returned directly for non-3DS cards. Your server receives this and redirects/updates the customer accordingly. - Without
callback_url: Posted to the parent page viawindow.postMessageand captured by yourmessageevent listener.
Kindly note that webhook notifications are only sent for successful card
transactions.
callback_url or via postMessage. Always check statusOk: false and read debugMessage for the failure reason.
Handling the payment result
After a card charge, the final payment result is delivered differently depending on whether you included acallback_url in the request.
Path A — With callback_url
When a callback_url is provided, Payaza POSTs the final payment result to that URL after the 3DS challenge completes (or immediately for non-3DS cards). The customer is redirected to your callback_url page.
Your callback_url endpoint must accept POST requests. Parse the body for statusOk and paymentCompleted to determine the outcome and complete your business logic (e.g. update the order, redirect the customer to a success or failure page).
Sample POST body received at callback_url
Handling the callback (Node.js / Express)
Path B — Without callback_url (postMessage)
When no callback_url is included in the Card Charge request, the final payment result is posted back to the parent page from the 3DS iframe using the browser’s window.postMessage API. Your page must have a message event listener in place before the charge is initiated.
Sample postMessage payload received in the browser
postMessage event listener
3DS challenge HTML document
This is the complete HTML document used exclusively for processing 3DS transactions. It handles the full charge request, renders the authentication challenge, and listens for the payment result — all in a single page. Use this as your reference implementation when building a 3DS-enabled checkout. Replace the card details and API key with your own values.This document does not include a
callback_url in the charge request. The
final payment result is therefore delivered via the internal
window.postMessage listener at the bottom of the script. If you add a
callback_url, the result will be POSTed to that URL instead — see Path A
above.3DS transaction page
- The iframe (
challengeFrame) renders the card issuer’s 3DS authentication page — the customer sees their bank’s OTP or biometric prompt inside it. result.formDatamaps to thecreq(challenge request) value that the ACS (Access Control Server) expects. Do not modify it.result.threeDsUrlis the ACS URL generated by Payaza for that specific transaction. It changes with every charge.- Replace
alert(...)with your actual UI logic — redirect the customer, update the order status, or render a success/failure component.
Step 2 — Check Transaction Status
Retrieve the final status of a card transaction by itstransaction_reference. Use this as a server-side fallback when a webhook is not received within your expected timeout.
Step 3 — Initiate Refund
Refund a completed card transaction — either the full amount or a partial amount.Refunds can only be initiated for transactions with
transaction_status: "Completed". Attempting to refund a failed or pending transaction will return
an error.Step 4 — Check Refund Status
Verify the current status of a refund using therefund_transaction_reference returned when the refund was initiated.
Step 5 — Fetch Refund History
Retrieve a paginated list of all refund transactions for your account. Results can be filtered by date range, currency, and refund status.
Sample response
Webhooks
Payaza fires webhook events for only completed card transactions. Webhook notifications are used in conjunction with TSQ API to get the status of card transactions Sample Successful Card Collection payloadAlways verify the webhook signature before processing the payload. See the
Webhooks guide for verification steps.
Error handling
Developer notes
- Always generate a unique
transaction_referenceper charge. The recommended maximum length is 15 characters. - For NGN card collections, the card
pinfield is required. For all other currencies, omitpin. - Choosing your result delivery method: Include
callback_urlin the request if you want the customer redirected to a page you control after payment. Omit it if you are building a single-page checkout and want to handle the result in the browser viapostMessage. - When
do3dsAuth: true, the payment is not yet complete — render the 3DS challenge before expecting any result. The final outcome arrives only after the customer completes the bank authentication. - When
waitForNotification: trueappears in a success response, it signals that a webhook notification will also follow. Fulfil the order only after receiving the final result — viacallback_url,postMessage, or a webhook — not based on the initial Card Charge response alone. - Save
refund_transaction_referencefrom every Initiate Refund response — it is the only way to check refund status later. - The
valueAmountin a successful response is the settlement amount after fees, and may differ fromamountPaid. UseamountPaidfor display to customers. - Use Fetch Refund History with date range filters for reconciliation — it includes the original transaction details nested inside each refund record.