Skip to main content
When a customer clicks a payment link, they’re taken to a Quidkey-hosted checkout page. This page collects their details, lets them select their bank, and redirects them to complete the payment — all without any frontend code on your side.

Customer Journey

1

Customer opens the link

The customer clicks the payment link URL you shared. Quidkey loads the hosted checkout page showing the merchant name, payment amount, and reference.
2

Customer fills in their details

The checkout page presents a form where the customer enters:
  • Full name
  • Email address
  • Phone number (E.164 format)
  • Country
These details are used to create the payment request and help Quidkey predict the customer’s bank.
3

Customer selects their bank

After submitting the form, Quidkey’s bank selection iframe appears. Quidkey automatically predicts and pre-selects the customer’s bank based on their country and information. The customer can change the selection if needed.
4

Customer authorizes at their bank

The customer is redirected to their bank’s authentication page (or mobile app) to approve the payment. This is the standard Open Banking authorization flow — the bank verifies the customer’s identity.
5

Payment complete

After authorization, the customer is redirected to a success or failure page. You receive a webhook notification with the payment result.

Checkout Page Layout

The checkout page uses a responsive two-column layout:
SectionContent
Left columnCheckout header, merchant name, customer form, bank selection (mobile), trust badges
Right columnOrder summary card: merchant avatar, payment reference, total amount, bank selection (desktop)
On mobile devices, the layout collapses to a single column with the order summary above the form.

Re-confirmation Support

If a customer has already submitted the form but hasn’t completed the payment (e.g., they closed the bank app), they can return to the same link and update their details. The checkout page allows re-confirmation — submitting the form again creates a new payment request with the updated customer information.
Single-use links remain active until the payment is actually completed (confirmed by the bank callback). This means a customer can retry or update their details as many times as needed before paying.

Status-Based Display

The checkout page adapts based on the payment link’s current status:
StatusWhat the customer sees
ACTIVEFull checkout form with payment flow
USEDMessage indicating the payment has already been completed
EXPIREDMessage indicating the link has expired
CANCELLEDMessage indicating the link is no longer available
Only ACTIVE links show the payment form. All other statuses display an informational message.

Security

The hosted checkout page is designed with security in mind:
  • Token-based access — Links use 256-bit cryptographic tokens. The token is hashed (SHA-256) before database lookup, so raw tokens are never stored.
  • No sensitive data exposure — The public checkout endpoint only returns the merchant name, amount, currency, and reference. Internal IDs, merchant IDs, and tracking data are never exposed.
  • Bank-grade authentication — Customers authorize payments directly in their bank app. Quidkey never sees banking credentials.

Next Steps