From applying to live
Any business applies free, for one website or one app. You build in the sandbox while SMP checks your business; when your build is done, the platform checks it case by case, a person at SMP looks at your real page, and your account goes live on that one site or app. Each review is answered within 2 business days.
- Apply free
The first page of the application asks for your business and the one website or app you will use the API on. Finish it and the page shows your sandbox key.
- Build in the sandbox
Test money only. Make the nine certification cases below with your sandbox key; the platform checks each one from your sandbox's own records.
- Send the page we should check
The checkout page on your website or app. A person answers within 2 business days and you see your place in line.
- Live on one website or app
Once your business check and your build are both approved. A second website or app is a new free application.
One website or one app
An account belongs to one website or one app, named on the first page of the application.
- A website is its domain, and every subdomain of it counts as the same website (
shop.example.com,api.example.com). - An app is its name, its platform (iOS, Android, a web app or desktop), its store link or bundle id, and the domain its server uses.
On the live API, checkout pages (allowed_origin) and webhook endpoints must be on that domain; anywhere else answers 400 validation_error. Every payment your keys make belongs to it. Changing the domain is done by SMP, on the record, and sends your build back to review.
Sandbox keys after the first page
When you finish the first page, the page shows your sandbox key once, with a copy button: store it before you go on. Your sandbox dashboard login arrives by email; the key itself is never emailed. Finish the rest of the application (owners, IDs, your payout bank, documents, signing) while you build.
The sandbox is a test bank inside the platform (the sandbox). Every email it sends is marked [Sandbox], and it never writes to the payer addresses you type in: payer invitations go to the sandbox's own outbox.
The nine certification cases
Make each case through the API with your sandbox key. There is nothing to fill in: GET / shows each case, what it waits for, and the ids it was checked against.
| Case | Passes when |
|---|---|
| Link a bank | A payer's bank account is linked through the sandbox's bank link (POST /). |
| A payment that settles | A WEB payment with SMP's authorization words, sent as their SHA-256, reaches settled. |
| A declined payment | A payment the risk checks decline, and your checkout tells the payer. |
| A returned payment | An R01 return, and its payment.returned webhook answered 2xx. |
| A refund | A refund of a settled payment. |
| A void | A payment voided before it was sent to the bank. |
| Webhooks received | payment.settled answered 2xx at your endpoint. |
| Webhook signatures checked | The sandbox sends your endpoint one event with a wrong signature (POST /), and your endpoint refuses it with a 4xx. |
| Retries are safe | The same payment sent twice with one Idempotency-Key makes one payment. |
The nine certification cases, each with what it waits for
The response · 200
HTTP 200
Cache-Control: no-store
{
"data": {
"method": "api",
"cases": [
{
"id": "bank_linked",
"passed": false,
"evidence": [],
"detail": "No payer bank is linked yet."
},
{
"id": "payment_settled",
"passed": false,
"evidence": [],
"detail": "No payment has settled yet."
},
… 7 more
],
"passed": 0,
"total": 9,
"ready": false,
"checked_at": "2026-10-28T00:23:30.675Z"
}
}
A WooCommerce store on SMP's own plugin has no cases to run: the plugin's self-test reports to the sandbox, and a person looks at your live checkout page once. With hosted checkout or invoices only, the page where your links appear is checked once.
Send your build for review
When every case has passed, send the checkout page to check with POST /: its address, on your website or app, and any notes. The answer gives the date it will be answered by, 2 business days later on the Federal Reserve's calendar, and your place in line.
Send the build for review: the page on the website the application names
curl -X POST https://onboard.socialmatterspay.com/v1/applications/current/integration/submit \
-H 'Authorization: Bearer applicant_session_token' \
-H 'Content-Type: application/json' \
-d '{
"page_url": "https://sunrise31.example/checkout",
"notes": "The authorization words sit above the Pay by bank button."
}'
A person at SMP checks the page itself:
- it asks for the payer's real name;
- it shows SMP's authorization words in full before the button, with a tick box that unlocks the button;
- it shows the amount, and for recurring debits the schedule, before the button;
- the payer gets a confirmation after paying, and sees the statement descriptor their bank will show;
- your refund policy and privacy policy are linked from the checkout;
- it is on the website or app named on your application.
If something has to change, the reviewer says what in their own words, by email, and the build waits for you to send it again.
Live
Your business check and your build are reviewed side by side; whichever is approved second makes your account live. Your live keys are on the live dashboard's Developers screen, and they take live payments only once the account is live. Fees start the day you go live: nothing is charged while you build.
SMP can switch an approved build off, with a reason on the record: new payments stop, and everything already on its way settles or returns as usual. Switching it back on is the same review again.
