Everything the merchant portal does by hand, you can do in code: take a payment on a checkout you designed, mint payment links from your own system, put customers on a recurring plan, and react the moment money arrives.
// Illustrative pseudocode. The real method
// names, fields, and response shape are in
// the API reference.
const atlas = createClient(ATLAS_API_KEY);
const link = await atlas.createLink({
amount: 180.00,
currency: 'USD',
description: 'Studio session'
});
// Then share it: message, email, QR code,
// or your own UI.Every snippet on this page is illustrative. They are here to show the shape of an integration — a key on the server, an object created, an event handled. They are not documentation. The exact base URL, endpoint paths, parameter names, response bodies, event names, and error codes live in the API reference, and that is the only source to build against.
All four sit on the same account, settle to the same bank account, and show up in the same dashboard as the payments you take by link or QR code.
Keep your own basket, your own pricing rules, and your own design, and hand the payment step to Atlas Pay. Cards are always accepted, and an eligible wallet is offered automatically. If you would rather not build one, the no-code eCommerce setup in the portal covers the same ground.
Generate a link when your own system decides it is time — a job finishes, a quote is accepted, an invoice falls due. Fix the amount or leave it open, then send it however you already reach the customer.
Put a customer on a repeat schedule from weekly to yearly, with a free trial of any length in days if you want one. Your application decides who goes on which plan; the billing runs on its own after that.
Have Atlas Pay call your server when a payment succeeds, a subscription renews, or a refund goes through, so your database and your customer's inbox stay in step without anyone polling anything.
Card Issuing Soon is designed to be driven from the API — virtual and physical cards, spending controls, and instant issuance for expense cards or payouts to gig workers. It has not launched, so there is nothing to call yet. Join the waitlist if you want to hear when it does.
There is no separate developer account to open. You verify your business once, then issue API keys to yourself from the merchant portal.
A key identifies your Atlas Pay account to the API. Your server sends it with each request; the API answers with your account's data and nothing else. Because the key can move money on your behalf, it belongs in server-side configuration only.
The header name, the key format, and the exact error returned for a bad key are specified in the API reference.
# Illustrative. The base URL, the paths and
# the parameters are in the API reference —
# <endpoint> below stands in for one.
curl -X POST \
https://api.atlaspay.com/<endpoint> \
-H "authorization: Bearer $ATLAS_KEY" \
-H 'content-type: application/json' \
-d '{ … }'
# The key is read from the server
# environment. It never reaches the page,
# the bundle, or the repo.
The API is the product; the SDKs are a convenience on top of it. Either way you are calling the same account.
Every endpoint with its parameters, its response, and its failure cases. This is the document to build against, and the one to believe when a snippet anywhere else disagrees with it.
Language libraries that wrap the same calls: they hold your key, sign the request, and hand back typed objects instead of raw JSON, so there is less of your own plumbing to maintain.
Step-by-step walkthroughs for the common shapes — a checkout, a recurring plan, an event handler — with the decisions explained rather than just the code pasted.
Not sure which you need, or which languages are covered for your stack? Ask us and we will point you at the right document.
A customer can close the tab the second after they pay. A webhook is what makes sure the order still ships, the seat is still granted, and the receipt still goes out.
// Illustrative. Header names, the signing
// scheme, and the real event names live in
// the API reference — the strings below
// stand in for them.
app.post(WEBHOOK_PATH, async (req, res) => {
const event = verifySignature(
req.rawBody, req.headers, SECRET
);
if (event.type === '<payment ok>') {
await fulfil(event);
}
res.sendStatus(200); // ack fast
});Which events exist, what each payload carries, and how deliveries are retried are all set out in the API reference.
The account comes first. Atlas Pay pays out to a real bank account, so the identity check and the bank link are not optional steps you can code around.
Sign up as the business that will be paid. This is the same account the mobile app, the merchant portal, and the desktop app all use — there is no separate developer sandbox account to keep in sync.
Verification unlocks payouts and the rest of the secure financial features; the linked bank account is where the money lands. Finish both before you start building, or your first successful call will have nowhere to settle.
Create a key for the thing you are about to build and store it in that service's server-side configuration. One key per integration keeps rotation boring. Nothing you build should read the key from the browser.
Start with the smallest useful thing — usually creating a payment link — and confirm it appears in the merchant portal. Seeing the object you just made in the same list as your manual ones is the fastest way to know the key and the account are wired correctly.
Stand up your webhook endpoint early, so the checkout, the subscriptions, and anything else you add later already have somewhere to report to. From there it is your own product logic, not ours.
Atlas Pay is live in 28 countries and pays out to eligible local bank accounts, with Nigeria in early access. Before you build, check that the market you are collecting in is covered — see Countries.
No. They show the shape of an integration, deliberately, and the placeholders in them are placeholders. Paths, parameter names, response fields, event names, and error codes are defined in the API reference, and that document is the one to code against.
From your merchant portal, once your account is verified. You issue keys yourself and you can revoke them yourself. Keep them in server-side configuration, use a separate key per integration, and replace any key that has been exposed.
No, and you should not want to. The customer enters their card on an Atlas Pay checkout, so card numbers never pass through your servers. You keep control of the basket, the pricing, and what happens after the payment.
Yes. It is one account. A link you create in code sits beside one you made on your phone, a WooCommerce order sits beside a QR code payment, and everything settles to the same bank account and appears in the same dashboard.
More general questions are answered on the FAQs page.
Pay buttons, editor blocks, and WooCommerce checkout, without writing any of it.
Coming soon, with nothing to install yet. See what is planned.
The no-code version: a catalogue and a checkout set up in the portal.
What you are usually creating in code, explained from the merchant's side.
Free to download
No monthly fee on Free
Live in 28 countries