The fastest integration is one you do not have to write
Most of an integration is the same every time: authentication, idempotency, signature verification, retries. SDKs and a shop plugin do that part, and they are built from the same table that serves the requests.
Look at any two payment integrations and most of the code is identical.
Authentication. Idempotency keys. Signature verification. Retries with backoff. Mapping errors onto something your application understands.
None of that is your product. All of it has to be right.
The part that is always wrong
Webhook signature verification is where hand-written integrations fail, and they fail quietly.
Common mistakes, all seen in the wild: comparing signatures with a normal string comparison instead of a constant-time one; verifying against the parsed body rather than the raw bytes; forgetting to check the timestamp, which leaves replay wide open; checking the timestamp but never actually rejecting on it.
Each of these produces an integration that works perfectly in testing and is wrong in a way that only matters on the day somebody is attacking you.
The SDK does it correctly, once.
Generated from the same table
The SDKs are generated against the same operation table that serves the requests and produces the documentation.
So an SDK cannot describe a call the platform does not have. It is not a hand-maintained wrapper drifting slowly out of date behind the API — it is another rendering of the same thing.
Where something brand new has not reached an SDK yet, the raw call always works. The SDK is a convenience, never a gate.
No dependencies
The Node SDK has none.
Adding payments to your project should not add a supply chain, a monthly round of advisories, and an upgrade you have to schedule. The fewer things you install to take money, the fewer things can go wrong in a way you did not choose.
For shops
The WooCommerce plugin ships in the repository rather than being published separately, so its version matches the API it was built against.
A shop owner installs it, enters a key, and takes payments. No developer required for the common case.
Test the failures first
Every SDK works against the sandbox, and the sandbox publishes magic numbers for specific outcomes — including a timeout that later succeeds.
Write your handler against that one first. It is the case that will find the bug in your retry logic, and it is much cheaper to find on a Tuesday afternoon than during your first busy weekend.
What it costs
Nothing. Open code in the repository, no licence.
What you can check
These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.
- SDKs are generated against the same operation table that serves the requests, so they cannot describe a call the platform does not have.
- Webhook signature verification is implemented in the SDK, which is where most hand-rolled integrations get it wrong.
- The shop plugin ships in the repository rather than being distributed separately, so its version matches the API it was built against.
- The Node SDK has no dependencies, so adding payments does not add a supply chain.
What it costs
Free. Open code in the repository, and no licence to use them.
Is it switched on?
Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: SDKs and plugins on the features page.
Read next
- The gateway API — Three calls and a webhook.
- Signed webhooks — Your software finds out before your customer does.
- Hosted checkout — A page that only offers what will work.
Frequently asked questions
Do I have to use an SDK?
No. The API is plain HTTP with JSON and is documented completely. The SDKs exist to save you from writing signature verification again, not to hide anything.
Which languages?
Node, PHP and Python, plus a WooCommerce plugin for shops. The Node SDK deliberately has no dependencies.
Will the SDK fall behind the API?
It is generated against the same operation table the API is served from, so it cannot describe a call that does not exist. Where a brand-new capability has not reached an SDK yet, the raw call always works.
Send with a QR code, add money by card or mobile money, issue a virtual card. Sandbox balances let you explore before any real money moves.
Keep reading
L’intégration la plus rapide est celle que vous n’avez pas à écrire
L’essentiel d’une intégration est le même à chaque fois : authentification, idempotence, vérification de signature, reprises. Les SDK et une extension de boutique font cette partie, et ils sont construits depuis la même table qui sert les requêtes.
How to build for a switch you are not connected to yet
Waiting for a scheme to publish its profile before writing any code wastes a year. Writing against an internal contract, with a simulator for the ugly cases, means the connection becomes a codec rather than a rebuild.
How a payment decides which way to go
A payment can usually travel several ways, and they are not equally good at two in the morning. Routing on measured success, cost and latency — with a breaker on failing rails — is the difference between resilience and a bad night.