REST API & reference
Standard REST conventions with predictable JSON, callable from any language. Request the full reference with your sandbox access.
Developers
Build on the GivePayments API
A modern REST payment gateway API, tokenization, hosted pages, webhooks, SDKs, and a sandbox to build against, with plugins for WooCommerce and the carts you already run. The difference from a generic developer platform is the account behind it: high-risk underwriting depth, so the integration you ship stays live as your volume climbs.
- REST API & predictable JSON
- Sandbox keys to build against
- High-risk-ready account behind it
Answer first
Developer-grade tooling on a processor that won't drop you
Most payment APIs are evaluated on the developer experience alone, REST conventions, clean docs, a sandbox, SDKs. Ours has all of that, and if that were the whole story there'd be little to choose between us and any modern gateway. But for a high-risk business, the developer experience is the easy half. The hard half is whether the account your integration runs on will still be open in a year, because a flawless integration on a frozen account processes exactly nothing.
So this hub gives you both. The tooling is what you'd expect: a REST API with predictable JSON, tokenization and hosted pages that keep card data out of your environment, webhooks so you build on events instead of polling, SDKs for the common languages, and a sandbox to validate the whole flow before you go live. Underneath it is the part that actually matters for a high-risk developer, an account that was underwritten for your vertical, not one waiting to be flagged by an automated risk model the month you grow.
Quickstart
Three steps to a test charge
1
Request sandbox access
Tell us what you're building and get sandbox keys plus the API reference, so your team starts integrating immediately, in parallel with underwriting, not after it.
2
Integrate with the toolkit
Use tokenization, hosted pages, SDKs, and webhooks to wire up your flow. A hosted-checkout integration can be live very fast; a custom build follows the same documented patterns.
3
Test, then go live
Run test charges, refunds, and webhook events in the sandbox. When the merchant account boards through underwriting, swap to live keys and ship.
The toolkit
What you build with
Sandbox & test keys
A test environment to run charges, refunds, and webhook events end to end before a real card is ever involved.
SDKs & libraries
Coverage for the common languages, so you call typed methods rather than hand-rolling HTTP requests and signatures.
Plugins for carts
WooCommerce, Shopify, and similar carts connect through the gateway, high-risk-ready processing on the store you already run.
Webhooks & events
Payments, refunds, disputes, payouts, and subscription events pushed to your endpoints in real time. Build on events, not polling.
Tokenization & hosted pages
Exchange card numbers for tokens on PCI-aligned infrastructure and capture cards on hosted pages, keeping card data out of your environment.
Build on events
Webhooks, not polling loops
Register your endpoints and payments, refunds, disputes, payouts, and subscription events stream to them in real time, available in the sandbox so you can test your handlers before going live. The same data surfaces in portal analytics, so you build on events and watch performance in one place rather than writing a timer to ask the API what changed.
- Real-time event delivery to your endpoints
- Events available in the sandbox for testing
- One API for one-time, recurring, and multi-party flows
The part that matters
The account behind the API was priced for your risk
Here's the spec that doesn't appear in any API reference but determines whether your integration matters next quarter. Mainstream gateways pair good tooling with mainstream underwriting, fine until your business trips a generic risk model and the account closes. Because GivePayments underwrites high-risk verticals natively, the account your integration runs on was reviewed and priced for your risk before it processed a dollar, and it's managed for fraud and chargebacks rather than frozen at the first dispute spike.
For a developer at a high-risk business that's the whole point: you want a clean integration, yes, but you need it attached to something that stays live. Build against the sandbox today, ship against an underwritten account when it boards, and connect through the gateway API or a cart plugin depending on how custom your flow is. The tooling is the easy promise; the account that survives is the one we actually compete on.
Where to go next
Sales page, security, and the carts
If you're scoping the commercial side rather than the code, the payment gateway API solution page covers what the platform does and who it's for. The security page details tokenization, hosted pages, and PCI posture if that's what your review needs. And the integrations page lists the current cart and stack connections, WooCommerce, Shopify, and the rest, for when a pre-built plugin gets you live faster than a custom build.
However you start, the fastest path is to request sandbox access or talk through your integration with the platform team. We'll point you at the right pattern, hosted checkout, full custom, or platform, confirm we board your vertical, and get keys in your developers' hands so the build runs alongside underwriting instead of waiting on it.
FAQ
Developer FAQ
Is there a sandbox?
Yes. Before you process a live dollar you can integrate against a test environment with sandbox keys, run test charges, refunds, and webhook events, and confirm your flow end to end without touching a real card. Request sandbox access through our platform team and you get keys plus the API reference, so your developers can build and validate the integration in parallel with underwriting rather than waiting on the account to go live first.
Which languages and SDKs are supported?
The API is plain REST with predictable JSON, so you can call it from any language that can make an HTTP request. On top of that we provide SDKs covering the common languages, so instead of hand-rolling requests and signatures you're calling typed methods. If your stack isn't covered by an SDK, the REST endpoints and reference are all you need, nothing about the integration depends on a specific library.
Do you have a WooCommerce plugin?
Yes, GivePayments connects to WooCommerce as a high-risk-ready gateway, so a WordPress/WooCommerce store can process cards and recurring payments through an account underwritten for its category rather than a mainstream plugin that freezes when disputes climb. Shopify and similar carts connect through the gateway as well. For anything beyond the pre-built cart connections, the same API and webhooks drive fully custom checkouts. See the integrations page for the current cart and platform connections.
How do webhooks work?
You register endpoint URLs and we push events to them in real time, payments, refunds, disputes, payouts, and subscription events, so you build on events instead of polling for changes. Each event carries the data you need to update your own system the moment something happens on the account. Webhooks are how a production integration stays in sync without hammering the API on a timer, and they're available in the sandbox so you can test your handlers before going live.
How do I get API keys?
Sandbox keys come with sandbox access, which our platform team provisions so your developers can start building immediately. Live keys are issued once the merchant account is approved through underwriting, because the account behind your integration is reviewed and priced for your vertical before it processes real money. So you build and test against the sandbox right away, and flip to live keys when the account boards. Start by requesting sandbox access or talking through your integration with the platform team.
Related
Keep exploring
Build on an API that won't disappear.
Request sandbox access or walk us through your integration. We'll point you at the right pattern, confirm we board your vertical, and get keys in your developers' hands.