Build once. Ship every channel.
Paytia is a development environment for payments — one REST API layer between your application and every payment network, plus a central record that every party in a deal can read their own slice of. Change acquirer, add a channel or bring in a partner without rewriting your integration.
- PCI DSS Level 1 service provider
- Separate staging and production systems
- OpenAPI specification and Postman collections
- Webhook-driven state, with delivery logs you can query
What you get on day one
A payment platform you can code against — without inheriting card data, PCI scope, or a gateway integration per acquirer.
One endpoint drives telephone payments, payment links, QR codes, SMS, hosted and embedded checkout, tokenisation, recurring plans, bank capture and out-payments.
- Base URL
- accounts.paytia.com
- Auth
- X-API-KEY · access_token
- Support
- techsupport@paytia.com
A development environment, not just an endpoint.
Payments projects stall on the same three problems. PCI scope creeps into the codebase, every acquiring bank speaks a different dialect, and each new channel means another integration. The split below is what removes all three from your backlog.
Your team owns
Business logic and UX
- Map your order and customer data to Paytia fields
- Decide where the payment surface appears
- Consume webhooks and update your records
- Handle positive, negative and exception flows
Paytia owns
Everything sensitive
- Card and bank data capture, encryption and tokens
- The PCI DSS Level 1 environment and its audit
- Gateway, bank, card authentication and phone-line plumbing
- Retryable webhook delivery and a full audit trail
Never build again: PCI perimeter
Card data is entered on the cardholder’s own keypad or a Paytia-hosted surface. It never traverses your servers, logs or call recordings.
Never build again: gateway adapter
One request shape for every acquirer and gateway we support. Switching is configuration, not a project.
Never build again: channel per surface
Phone, AI voice, link, QR, SMS, embedded checkout and bank rails all come off the same call with a different flag.
Same request, ten behaviours.
Your application posts a single request shape. Paytia normalises it, applies the merchant licence and routing rules, and speaks the native dialect of whatever sits behind it. The behaviour you get is chosen by one field: transaction_flag.
| Flag | Behaviour | What your product gets |
|---|---|---|
| 0 | Immediate charge | Take the full amount now, on the call or on a page. |
| 1 | Capture to token | Card on file with no charge — store a token, charge later. |
| 2 · 3 | Pre-auth | Reserve funds with an immediate payment (2) or reserve only (3). |
| 4 | Link to Pay | Payment link, QR code or SMS — asynchronous collection. |
| 5 · 6 | Recurring · bank-to-bank | Subscription plans and bank-rail transfers. |
| 7 | Rolling reserve | Rolling-reserve handling for staged billing. |
| 8 | Checkout | Product and shipping flow for web checkout. |
| 9 | Bank out-payment | Pay money out to a tokenised bank account. |
A new payment method, acquirer or channel is normally a project. Behind one API layer it is a field value, a licence and a test run. The full field list is in the field reference.
Pick the pattern that fits your architecture.
The same platform is reachable five ways. Choose by how much of the payment experience you want to own — and change your mind later without touching your business logic.
Embedded iframe
Someone completes a payment inside your UI. Post the transaction, render the returned capture surface in your own screen, and listen to postMessage events.
URL-encoded POST
For applications that can only build a URL string. Post every field as query parameters and Paytia redirects into a completed capture form, pre-filled from your data.
Server to server
A pure API post — no iframe, no UI. Charge a stored token, amend a plan, complete a two-stage payment, or push a bank out-payment. Status arrives on webhooks.
Webhook only
“Just tell me when it’s paid.” Paytia owns the payment surface; your system receives the authoritative result and reconciles itself.
Switch-on connector
Where records already live in a connected system, Paytia searches, matches and settles against them. No code — a licence and a one-time authorisation.
Design rule
Render optimistically from browser events; commit state only on the webhook. Every delivery is logged and retrievable, so reconciliation is a query rather than a support ticket.
One record, many parties.
The hardest payment problems are organisational rather than technical. Most payments involve more than two organisations — a merchant, a broker or agency, an accounting system, an acquirer, sometimes a funder or an insurer. Paytia holds one authoritative record per transaction and gives each party exactly the fields they are entitled to see.
| Party | Sees |
|---|---|
| Your application | Full order context, outcome, token reference, agent and call detail. |
| Partner, agency or broker | Scoped by store ID and API key — their own transactions only. |
| Accounting platform | Amount, reference, status; matched to the invoice it settles. |
| Nobody in your estate | Card numbers, card security codes or bank credentials. |
Read the record back
Five reporting endpoints share one envelope, with date, status and search filters. On the day something looks wrong in production, these are what you reach for.
- Payment historyRecords for reconciliation and reporting
- Call logsCall detail for channel and agent reporting
- Call log detailEverything about one call
- API traceThe exact request and response Paytia exchanged
- Webhook logWhat we posted to you, and the code you returned
From API key to production.
A documented specification, a real staging system, pre-built collections, and a support desk that speaks to engineers.
Get your key
Merchant portal, then Account Security, then API secret key. Every call carries the X-API-KEY header.
AuthenticationTest on staging
Import the Postman collection, set the key and exercise a call. Live accounts can also run against the gateway in test mode.
Getting startedHandle both outcomes
Build the positive and negative flows plus exceptions, then switch to the live key with production webhooks over HTTPS.
ExceptionsBehind the layer
Card gateways and acquirers including Stripe, PayPal and Braintree, Adyen, Elavon, Lloyds Cardnet, NatWest Tyl and ACI Worldwide, with orchestration via BridgerPay, bank rails via Acquired.com, and wallets via Apple Pay and Google Pay.
Multi-gateway merchants route per transaction, so one codebase can serve several entities, brands or currencies. The full API documentation covers every service and field, with a live explorer on each flow.
Questions engineers actually ask
Do we need our own PCI environment to use the API?+
No — that is the point of the split. Card data is entered on the cardholder's own keypad or a Paytia-hosted surface, so it never traverses your servers, logs or call recordings. Your application handles order data and business logic; the PCI DSS Level 1 environment and its annual audit sit on our side. See the platform for how scope reduction works.
How much work is it to switch acquirer or add a gateway?+
Configuration rather than a project. Your application posts one request shape; Paytia normalises it and speaks the native dialect of the gateway, acquiring bank or bank rail behind it. Changing what sits behind that layer does not change the contract between you and us, so your integration code stays as it is.
What is the difference between the iframe events and the webhooks?+
Use browser events for interface behaviour and webhooks for truth. The iframe posts messages for things like auto-height, which payment method the customer picked, and payment status — useful for rendering. The webhook is the authoritative record. The design rule is to render optimistically from the browser events and commit state only on the webhook.
Can we test properly before going live?+
Yes. There is a separate staging system for pre-release testing, and live accounts can also run against the gateway in test mode. Import the Postman collection, set your key and exercise a call. Build the positive and negative flows plus exceptions before you switch to the live key — the exceptions reference covers what to handle.
A payment did not arrive in our system. How do we debug it?+
Two reporting endpoints answer that directly. One returns the exact request and response Paytia exchanged for a call, so you can see what we sent. The other shows the webhook payload we posted to you, your HTTP response code, and whether delivery succeeded. Between them, reconciliation is a query rather than a support ticket — see the reporting API.
Can one integration serve several brands, entities or currencies?+
Yes. Multi-gateway merchants route per transaction, so a single codebase can serve several entities, brands or currencies. Where one party sells and another takes the money, each is scoped by their own store ID and API key, and the outcome fans out to each system on its own webhook.
One API layer. One shared record.
Tell us what you're building and which channels you need. We'll map it to the API, get you a staging key, and stay with you through the first integration.
Trusted by law firms, insurers, healthcare providers and regulated businesses worldwide. Learn more about Paytia