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.
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.
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
Paytia owns
Everything sensitive
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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