The map of a payment

People

Merchants, their customers, and the Soap team.

Customer

The person paying a merchant, or being paid out by one, in Soap's checkout.

Merchant

A business that takes payments and sends payouts through Soap.

Developer

The merchant's engineer who connects their product to Soap's API.

Soap team

Operations, support, underwriting and engineering, working alongside AI agents.

Surfaces

What people actually touch: checkout, onboarding, the merchant dashboard and the API.

Hosted checkout

The payment page customers see. Cards, digital wallets, bank payments and payouts in one flow.

Merchant dashboard

Where a merchant sees payments, customers, disputes and reviews, and manages API keys.

Onboarding

Where a new merchant applies, uploads documents and verifies who they are.

Merchant API

The API a merchant's server calls to create customers and checkouts.

SDK

A typed client for the Soap API.

Docs

Guides and the API reference for developers.

Edge

Where every request enters the system.

Edge network

Receives every request, close to the person making it.

Load balancer

Spreads requests across the backend so no single server carries the load.

App hosting

Serves the checkout, the dashboard and the onboarding app.

One backend

Runs every provider, every webhook and every background job.

Backend

One service behind every surface. It runs each checkout step by step and talks to every provider.

Routing

Moves a payment to the next processor when one says no.

Webhook intake

Receives updates from partners, checks they are genuine and applies each one once.

Background jobs

Work that runs after the request: retries, notifications and scheduled checks.

Merchant events

Signed webhooks that tell the merchant's server what happened to each payment.

Compliance

Checks that run before a single dollar moves.

Identity verification

Confirms a customer is who they say they are before money moves.

Business verification

Checks a merchant's business, documents and signer during onboarding.

Location check

Confirms the customer is somewhere the merchant is allowed to serve.

Device check

Recognizes the device behind a payment.

Multi-account detection

Spots one person operating several accounts.

3D Secure

Has the cardholder's bank authenticate a card payment before it is charged.

Name matching

Checks the name on the payment method against the verified customer, with AI to recover honest mismatches.

Payment reviews

Holds a flagged payment or payout until a person approves it.

Restrictions

Stops a risky customer from depositing or withdrawing until the issue is resolved.

Transaction monitoring

Watches activity over time for patterns a single check would miss.

One ledger

Records every charge, dispute and payout.

Ledger

One record of every charge, refund, dispute and payout, and every change to them.

Job queue

Holds background work until a worker picks it up.

Document storage

Keeps onboarding documents and dispute evidence.

Onboarding records

Merchant applications and where each one is in review.

Partners

The processors, banks and specialist providers around the core.

Card processors

Authorize and settle card payments. Soap works with several behind one integration.

Card vault

Stores card details so they never touch the merchant's or Soap's servers.

3D Secure provider

Runs the authentication with the cardholder's bank.

Digital wallets

Apple Pay and Google Pay.

Pay-by-bank network

Moves money straight from a customer's US bank account.

Bank linking

Lets a customer connect their bank account securely.

Payout provider

Sends payouts to bank accounts and cards.

Lightning provider

Creates and settles Lightning invoices.

Payment apps

Apps a customer can pay from, such as Cash App.

Stablecoin rails

Stablecoin payouts and settlement.

Identity providers

Check documents and biometrics for identity verification.

Device intelligence

Identifies devices and scores risky connections.

Geolocation

Turns a position into a place, for the location check.

Sign-in

Authenticates merchants in the dashboard and the onboarding app.

Email delivery

Sends verification codes and notifications.

E-signature

Collects signatures on merchant agreements.

AI models

Language models behind document review, name matching and dispute evidence.

Monitoring

Errors, metrics and alerts, so problems are seen before customers report them.

Card deposit

A customer pays a merchant by card in the hosted checkout. The card goes to a vault, the payment goes to a processor, and the result lands on the ledger.

1. The customer opens the merchant's checkout link.
2. They type their card into fields hosted by the card vault, which returns a token.
3. The checkout submits the payment.
4. The request reaches the backend.
5. Compliance checks run before any money moves.
6. Routing picks a processor for this payment.
7. The sale goes to the processor through the vault, so the card number stays out of Soap.
8. The answer is recorded on the ledger.
9. The merchant's server gets a signed webhook with the result.
10. The customer sees the payment succeed.

Card deposit with 3D Secure

Before a typed card is charged, the cardholder's bank authenticates the payment. A successful check travels with the sale.

1. The customer submits a card payment.
2. The backend decides this payment needs 3D Secure.
3. A 3D Secure session opens with the provider. The card number stays in the vault.
4. The customer's bank checks the payment, and asks for a challenge only when it needs one.
5. The result of the check is stored.
6. The sale goes to the processor carrying proof of the authentication.

Apple Pay deposit

A customer pays with Apple Pay. The wallet's encrypted payment is opened inside the vault and charged without the card ever being typed.

1. The customer taps the Apple Pay button.
2. The checkout asks the backend to start a wallet session.
3. The wallet confirms the merchant is who it claims to be.
4. The customer approves with Face ID or Touch ID.
5. The vault opens the encrypted payment and keeps the card details.
6. The processor charges the wallet payment.
7. The charge is recorded, and the merchant is notified.

Google Pay deposit

A customer pays with Google Pay. The encrypted payment is opened inside the vault and sent to the processor.

1. The customer picks a card in the Google Pay sheet.
2. The wallet hands the checkout an encrypted payment.
3. The checkout passes it to the backend.
4. The vault opens it and keeps the card details.
5. The processor charges the payment.
6. The charge is recorded, and the merchant is notified.

Pay by bank

A customer links a US bank account and pays straight from it. There is no card chargeback process, but a bank payment can still be returned.

1. The customer chooses to pay by bank.
2. They sign in to their bank to link the account.
3. The checkout submits the payment with the linked bank.
4. The backend asks the network to debit the account.
5. The accepted payment is recorded.
6. The merchant is notified.
7. If the bank later returns the payment, the network tells Soap.
8. The payment is marked returned, and the merchant is notified again.

Cash App deposit over Lightning

A customer pays from Cash App by paying a Lightning invoice that Soap creates for the exact amount.

1. The customer picks Cash App and taps Pay.
2. The backend creates a Lightning invoice for the amount.
3. The checkout opens Cash App with the invoice.
4. The customer confirms the payment in Cash App.
5. The payment arrives over Lightning in seconds.
6. The provider tells Soap the invoice was paid.
7. The backend confirms it and completes the checkout.
8. The merchant is notified.

Card deposit confirmed later

Some card payments do not get a final answer straight away. Soap shows the payment as pending and finishes it when the processor confirms.

1. The customer submits a card payment.
2. The processor accepts the payment but has no final answer yet.
3. The customer sees that the payment is processing.
4. The processor sends the final result.
5. The payment moves from pending to succeeded or failed.
6. The merchant is notified of the final result.

Payout to a customer

A merchant pays a customer out. The customer picks where the money goes, checks run, and a flagged payout waits for a person.

1. The merchant's server opens a withdrawal for the customer.
2. The customer chooses an amount and where to receive it.
3. A one-time code confirms the payout method is theirs.
4. Identity, device and multi-account checks run.
5. If the merchant reviews payouts, this one waits for approval.
6. The merchant approves it in the dashboard.
7. The payout is sent, in real time where the receiving bank supports it.
8. The provider confirms the money has landed.
9. The merchant is notified.

Refund

A merchant refunds a card payment from the dashboard or through the API.

1. The merchant clicks Refund on a payment.
2. The backend checks the payment can still be refunded.
3. The refund goes to the processor that took the payment.
4. The payment is marked refunded.
5. The merchant's server is notified.

Risk screening before money moves

Every check is a step in the checkout, switched on per merchant. A failed check stops the payment before a processor ever sees it.

1. The checkout reports the device and, where needed, its location.
2. The location is compared with where the merchant may operate.
3. The customer verifies their identity, once.
4. The device is recognized.
5. The device and payment method are compared with other accounts.
6. The name on the payment method is matched to the verified customer.
7. A failed check restricts the customer, with a reason.
8. The merchant reviews matches and restrictions in the dashboard.

Dispute evidence

When a customer disputes a card payment, Soap records it, restricts the account and helps the merchant build the evidence.

1. The processor reports a new dispute.
2. The dispute is recorded against the payment.
3. The customer is restricted while the dispute is open.
4. The merchant's team is emailed.
5. The merchant opens the dispute and adds what only they hold.
6. Their documents are stored with the dispute.
7. AI drafts the evidence report from the payment record and the documents.
8. The merchant reads the report and submits it.

Support: from failed payment to resolution

Every failed step is already on record, so a merchant can see why a payment failed and fix it without opening a ticket.

1. A customer's payment fails or is restricted.
2. The backend has recorded each step and why it stopped.
3. The merchant sees the issue in their support queue.
4. They ask why it failed.
5. AI writes a short explanation from the record.
6. The merchant lifts the restriction or resolves the issue.

Merchant onboarding

A new merchant applies once. AI checks the application as it is filled in, people handle what needs judgment, and the merchant ends up with a live account.

1. The merchant fills in a short intake form.
2. Soap matches the business with processors that fit it.
3. The merchant completes the application and uploads documents.
4. AI checks each answer and document as it is submitted.
5. The person signing verifies their identity.
6. The merchant signs the agreement.
7. An underwriter reviews the application, with an AI assistant.
8. The approved merchant gets a dashboard account.

Merchant API integration

A developer connects a product to Soap with an API key, two calls and one webhook.

1. The developer copies an API key and sets a webhook address.
2. The merchant's server creates a customer.
3. It creates a checkout and gets back a link.
4. The customer opens the link and pays.
5. Every change to the payment is recorded.
6. Each change queues an event.
7. The merchant's server receives a signed webhook, retried if it does not answer.
8. The customer is sent back to the merchant's product.