Paayed's public payments API lets a developer take a card payment against a Paayed merchant, using credentials created entirely by them — no onboarding call required to get started. The API is shaped like Stripe's, so an integrator moving from Stripe should find the translation mechanical. The acquirer behind it is never visible.
POST /v1/payments with the customer, the order items, the card and an idempotency key.succeeded, declined, failed, or requires_action when 3-D Secure is needed, with a challenge to complete it. Failed and declined results return HTTP 402 with the payment object.curl -X POST 'https://gateway.uk.paayed.com/v1/payments' \
-H 'Authorization: Bearer pyd_secret_live_...' \
-H 'Idempotency-Key: 5f1e6a6c-9d3f-4a2f-9a1e-2b7c1d9e4f88' \
-H 'Content-Type: application/json' \
-d '{
"amount": 42.50,
"currency": "GBP",
"reference": "ORDER-10023",
"payment_method": {
"type": "card",
"card": { "number": "4242424242424242", "expiry_month": 12, "expiry_year": 2029, "cvc": "123" }
}
}'{
"id": "pay_01JBQ7X2F9KDNW3M8T",
"object": "payment",
"status": "succeeded",
"amount": 42.50,
"currency": "GBP",
"livemode": true
}No SDK required. Any HTTP client will do.
Create and refund card payments, with 3-D Secure built in — or send the cardholder to a hosted session and never handle card data. Authorize-then-capture and cancel arrive in a later version.
Store a card once with the cardholder present, then charge it on a fixed schedule as a merchant-initiated transaction.
Customer records and their stored payment methods, shared across payments, hosted sessions and subscriptions.
Send the cardholder to Paayed's page from your website or app to take a payment or start a subscription. Card data never reaches your servers.
Signed webhooks for every state change, retried for two days, with a 30-day event log as a backstop.
Most of the contract maps to Stripe's field for field: the same idempotency header, the same webhook signing scheme, the same event-log recovery mechanism. Where a name differs — our identifier prefixes, our own decline code taxonomy — it's because the Stripe name carried history we don't need. See the migration guide in the API reference for a full field-by-field comparison.
Amounts travel as decimal major units (42.50, not 4250), validated against the currency's exact decimal places on the way in. Every write requires an Idempotency-Key; a retried timeout can't take a payment twice.
Create a sandbox key immediately and start building. Create a live key at the same time — it's usable the moment your account goes live, so nothing changes on the day you switch over. Both use the same hostname; the key decides the mode.
Every response is mapped into a Paayed-owned taxonomy before it reaches you. No field, error code, status string or webhook payload identifies our processing partner.
Get your API key
Open Developers → API keys in the dashboard and create a sandbox key. It works immediately against the simulator.
Take a test payment
POST /v1/payments with one of the sandbox test cards. Try 4000 0000 0000 3220 to see the 3-D Secure flow.
Handle 3-D Secure
When a payment comes back requires_action, POST a browser form to next_action.challenge.acs_url with creq and, when present, threeDSSessionData from next_action.challenge.three_ds_session_data. Forward both values unchanged. If your integration receives the issuer's cres, submit it from your server to POST /v1/payments/{id}/confirm; managed callbacks handle that step for you. Fulfill from the webhook, and retrieve the payment to show its result. See the 3-D Secure walkthrough.
Set up webhooks
Register an endpoint for payment.succeeded, payment.declined and refund.succeeded at minimum. Verify every signature before you trust the payload.
Go live
Create a live key any time — it authenticates once your merchant account is active, with no other change to your integration.