Go-live checklist

Before Hubpay enables production access for a payments integration, we ask you to show — in the sandbox — that the critical payment paths work correctly. This page lists what to show and what to confirm.

We keep this short on purpose. Hubpay can already see your API calls and webhook deliveries on our side, so we do not ask you to prove those. Evidence is only needed for the parts that happen inside your system, where we cannot see them — above all, how your integration decides that a payment is real before delivering anything.

How it works

1. Build and test your integration in the sandbox, following the guides and the sandbox simulation tools.
2. Download the evidence pack form: Download the evidence pack (Word document). It mirrors this page item for item.
3. Complete the evidence items (part 1) and tick the confirmations (part 2). Evidence items 1–3 apply to every integration; only the crypto and mobile items can be N/A.
4. Send the completed document to your Hubpay implementation manager, or email it to engineering@hubpay.ae.
5. Hubpay reviews it, confirms the results, and enables production access.

Types of proof

• Copy of response — the full API response or webhook event, pasted as text. You do not need to pick out specific fields. Hide API keys, signing secrets and personal data before sending.

Additional evidence is welcome but not required. Anything that shows the behaviour more clearly helps the review go faster — for example screenshots of your logs or admin screens, extra webhook payloads, or short recordings. Attach it to the item it belongs to.

---

Part 1 — Evidence items

The key rule behind this section: what the payer's browser shows is never proof of payment. The redirect to your success page, the checkout success screen, and the hubpay:success event in an embedded integration all mean the same thing — the payer finished their steps, not that money arrived. Delivery of goods or services must follow verified webhooks and API state, as described in Payment lifecycle and webhooks.

#	Show us	Proof to send
1	You can create a payment request with the correct executionMode and payer details. (This also proves your authentication works.)	Copy of response: the request and response of one payment-request creation.
2	A full payment works end to end: the payment.completed event arrives, you fetch the payment request with GET /v1/collections/payment-requests/{id}, check the status the API returns, and mark the order paid exactly once.	Copy of response: the payment.completed event from one simulated full payment, and the payment request your system fetched after it.
3	If the payer pays less than the full amount, the request becomes PART_PAID and you do not deliver in full.	Copy of response: the payment request fetched after one simulated underpayment, showing PART_PAID.
4	Crypto only. A crypto payment is confirmed only when all three are true: the event is v1.collection.payment_request.payment.completed, its signature is valid, and the payment status from the API is COMPLETE. payment.received, payment_request.paid and status RECEIVED are never treated as final.	Copy of response: the events you received from one simulated crypto payment, and one sentence confirming the order was marked paid only after payment.completed with status COMPLETE.
5	Mobile apps with crypto payments only. The payment page works inside your app on a real phone, including a crypto wallet payment opening the wallet app — see Mobile apps and WebViews. Card- and bank-only mobile integrations can mark this N/A.	One or two sentences confirming the test and which wallet you used. (Screenshots or a screen recording are welcome as additional evidence.)

Part 2 — Confirmations

Tick each statement to confirm it. No evidence is needed — these are covered by the declaration at the end of the form. Only the statements marked with a scope — hosted payment page, embedded, or mobile apps — can be N/A; every other statement applies to every integration.

• Nothing is delivered, invoiced or marked as paid when the payer finishes the checkout (your success page, or the hubpay:success event). Delivery only happens after the checks in evidence item 2.
• You verify the signature of every webhook against the raw request body, and events with a bad signature are rejected — see Verifying webhook signatures.
• If the same event arrives twice, the action happens only once — you deduplicate by event ID.
• Your API key and webhook signing secret are stored on your server only, in a secret manager — never in websites, mobile apps, code repositories or logs.
• Your webhook endpoint answers quickly with a 2xx status; slow work happens in the background, and no handler depends on events arriving in a particular order.
• Your team finds out when webhook deliveries fail — through monitoring, alerts, or a regular job that checks payment statuses through the API.
• An expired payment session is refreshed with the refresh payment session API, or a new link is sent — the payer is never left on a dead page.
• (Hosted payment page only) successRedirectUrl and cancelRedirectUrl are set, and both pages exist. (Payment links shared by email, SMS or CRM do not need return pages.)
• (Embedded only) The iframe URL keeps the returned paymentUrl and adds embedded=true and origin; your message listener checks the event origin and the sending window — see Embedded checkout.
• (Mobile apps with crypto payments only) The payment page opens in a browser sheet, or your WebView forwards non-http links to the phone, or — for Salesforce Mobile Publisher — the wallet schemes are allowlisted.
• You store the paymentRequestId and paymentId with your own order records, and your support team can look up a payment's state without a developer.

---

Submitting

Fill in the form's evidence boxes, tick the confirmations, and complete the declaration:

We confirm that this evidence reflects the integration that will run in production, that every confirmation ticked above is true, and that goods and services are only delivered after the checks in evidence item 2 pass.

Send the completed document to your Hubpay implementation manager or engineering@hubpay.ae. If you cannot meet an item, tell us during the review — in some cases a different control is acceptable, and we would rather discuss it early.