Skip to main content
Accept bank-to-bank payments with Quidkey: create a payment from your backend, send your buyer to a bank to approve it, and receive a webhook when it settles. Every integration path uses the same credentials, authentication, and webhooks. You choose how the payment is presented to the buyer. Want zero frontend work? Use a Redirect and send the buyer to a Quidkey-hosted bank page. Already running a Stripe checkout? Drop Quidkey in alongside it with the Embedded flow. Sending an invoice? Generate a Hosted Checkout link and share the URL.
Amounts are integer minor units on every Payment API endpoint (Redirect, Embedded, and Hosted Checkout): 1000 = £10.00, 2550 = €25.50. See Amounts & Currencies.
Before you start: sign up and grab your client_id and client_secret from the Quidkey Console. You’ll exchange them for an access token on your first call.

​
Base URL

All Payment API requests go to https://core.quidkey.com. There’s no separate sandbox host: set test_transaction: true to route a request to the sandbox (see Testing).
Always set test_transaction: true while developing so you never move real money. Test payments flow through the same endpoints and fire the same webhooks as live payments.

​
Three Ways to Accept a Payment

Every path uses the same OAuth credentials, integer minor-unit amounts, and webhooks. They differ only in where the buyer completes the payment and how much frontend code you write.
Redirect (Pay by Bank)Embedded (with Stripe)Hosted Checkout
Best forFast launch, full control of your own UIE-commerce checkouts already using StripeInvoicing, ad-hoc and no-code payments
Frontend effortRedirect the buyer to a URLEmbed an iframe + Stripe mutual exclusionNone: share a link
Buyer detailsCollected by you, sent at create timeCollected by you, sent at create timeCollected on the Quidkey checkout page
Buyer completes onQuidkey-hosted bank pageInline on your site, then their bankQuidkey-hosted checkout page
Amount formatInteger minor unitsInteger minor unitsInteger minor units
Need more than one? They all share the same backend API and webhook infrastructure, so you can mix them freely: Embedded on your checkout page, Hosted Checkout for invoice emails, and Redirect for a lightweight standalone flow.

​
The Create → Redirect/Embed → Webhook Model

Every Payment API integration follows the same three-beat rhythm, no matter which path you pick:
1

Create

Call the create endpoint for your chosen path with an authenticated request. You get back a redirect_url, a payment_token, or a payment_link_url.
2

Redirect or embed

Send the buyer to the bank page (Redirect / Hosted Checkout) or render the inline iframe (Embedded). The buyer approves the payment in their own bank.
3

Webhook

Quidkey sends a webhook to your backend with the final result. The webhook is the source of truth, not the browser redirect. Fulfil orders only when you receive quidkey.payment_request.succeeded. Webhook delivery is a single attempt with no automatic retry, so the merchant status endpoint is your reconcile backstop for any event you never received.

​
Start Here

Quickstart

Your first payment in about 10 minutes, end to end

Authentication

Exchange your client credentials for an access token

​
Accept a Payment

Redirect (Pay by Bank)

Create a payment and redirect the buyer to a Quidkey-hosted bank page

Embedded (with Stripe)

Add Quidkey alongside your existing Stripe Payment Element

Hosted Checkout

Generate a shareable checkout URL in one API call

​
Core Concepts

Authentication

Obtain, use, and refresh OAuth 2.0 access tokens

Idempotency

Send an Idempotency-Key so retries never create duplicate payments

Webhooks

Receive payment status updates and verify signatures

Errors

The error envelope, status codes, and how to handle failures

Amounts & Currencies

Integer minor units and ISO 4217 currencies across the Payment API

API Reference

Explore every endpoint with an interactive playground