Four checks. Every sale.
Government ID verification
Your customer photographs their ID and their own face. We confirm the document is real and that the face in front of the camera matches it.
Bank ownership, confirmed by the institution
Your customer signs in to the receiving bank. The institution confirms the account belongs to that person before the swipe is authorized.
Card bound to person, person bound to bank
The card, the verified person, and the receiving account are written as one record. A swipe that does not match the binding is refused.
A sealed record per sale
Every approved sale carries a sealed record you can produce the day someone disputes it.
Authentication is not identity.
3-D Secure, in money transfer
The card networks carve money transfer merchant categories out of the US liability shift. You can run the authentication step and still absorb the chargeback. Passing a challenge proves a device held the card. It does not prove who held the device, and it does not name the person who received the money.
The swipe answers back
Every swipe contradicts the claim. The claimant passed a government ID check. Their own bank confirmed the receiving account. The card was bound to that person before the money moved. You file a record, not a screenshot.
Swipe to Bank is designed to help you defend a dispute. Issuers and networks decide outcomes. Results vary.
What you show when someone says it was not them.
We keep the proof. Never the documents.
The ID photograph, the ID number, and the date of birth stay with the company that runs the check. We hold the confirmed name and the result. We never hold the document. Your records are yours alone, and no other account can read them.
A check that cannot run tells you so.
Stripe Identity verifies the person
Document capture, liveness, and the verified name come back from Stripe Identity. You never handle the document.
Plaid confirms the bank
Your customer signs in to the institution. Plaid returns the account and the owner on it.
When a check cannot run, you are told plainly. Nothing is ever simulated, and no record is ever invented.
Bind the identity before the first dispute lands.
Get startedFive steps. Two seconds at the counter.
Someone hands you a card. You need to know it is really theirs before you let the money move. Here is what happens, start to finish.
They prove who they are, once
Your customer photographs their government ID and their own face. That happens on their phone, on a page we host, so the document never lands on your systems or ours. It takes about ninety seconds and they never do it again.
Their bank confirms the account is theirs
They sign in to their own bank. The bank tells us the name on the account, and we check it against the name on the ID. A mismatch stops there, which is the single most common way stolen money tries to move.
The card, the person, and the account get tied together
One record holds all three. From that point on, that card can only send money to that person's own account. Somebody else holding the same card number gets nowhere.
You get a yes or a no, with the reasons
At the moment of the sale you ask, and you get back one answer and the facts behind it. Never a score you cannot explain to anyone.
Months later, you can still prove it
When a dispute arrives, you pull the record of everything you checked and when. It is sealed, so nobody can argue it was written after the fact. That is the difference between fighting a chargeback and eating one.
A check that cannot run says so.
If a bank is down or an ID cannot be read, you are told. You are never handed a quiet yes that was really a guess. Knowing you do not know is worth more than a confident wrong answer.
Get startedWhat people ask before they start.
How long does my customer wait?
About ninety seconds the first time. After that, two seconds, because they are already known.
Do I ever hold their ID?
No. It goes straight to the check and never reaches your systems, so it is never yours to lose.
What if a check comes back clean and it still goes wrong?
You hold the record of everything that was confirmed and when. Swipe to Bank is designed to help you defend disputes, and results vary.
Can my team connect this to what we already run?
Yes. Send whoever builds your systems to the developer guide.
Seven groups. Each answers one question.
You take the groups your operation needs and leave the rest. Forging one group does not help anyone forge another, and that independence is what you are buying.
Is this person or company who they say they are?
Is a real human physically here, right now?
Have we already done this work for this person?
Are they barred from doing business?
Do they control the money instrument they are presenting?
Should this transaction proceed?
Can I prove what I checked, months from now?
It fits where you already work.
Run the checks from your own counter, your own website, or your own back office. You take the groups you need and ignore the rest, and you are never charged per check.
At the counter
Someone hands you a card. You ask, and you have an answer before they put their wallet away.
On your website
A returning customer clears in about two seconds. A new one proves themselves once.
Wherever your team works
Whoever builds your systems can wire this in. Send them to the developer guide.
You see how many independent facts stand behind a person and when each was last confirmed. That is not a guarantee, and results vary.
Three ways operations run this.
Merchant checkout
Look the member up, confirm they are standing there, authorize, keep the evidence.
Payment redirection
Verify the person, confirm they control the destination account, authorize, keep the evidence.
Events
Look the member up at the door, confirm presence, admit.
Two plans. One price each month.
A person registers once and passes quickly at every merchant on the network. A business checks the person in front of them against that record. Both plans carry the whole product, and neither one is charged per check.
One price. Nothing added at the end of the year.
One line on your invoice
Your plan, billed in advance. There is no usage bill and no charge per check.
Evidence costs nothing extra
Pull the package on any swipe you already paid for, as often as a dispute needs it.
A failed check is not billed
A verification that comes back unverified does not count against your plan.
A business plan is paid for the full year up front. Prices are in US dollars. Swipe to Bank is designed to help you defend disputes, and results vary.
What the price covers.
Is there a limit on how many people I can check?
No. Registry lookups and authorizations run at the one price you already pay, and nothing is metered against you.
Do you charge for a verification that fails?
No. A check that comes back unverified does not count against your plan and does not add to your bill.
Are there extra costs on top?
No. Every check we run is already inside the price. Your invoice carries one line.
Can I change plans mid month?
Yes. You move up or down at any time, and the difference is prorated on your next invoice.
Am I tied into a contract?
No. Both plans run month to month. The twelve month option is there if you want it, and it is your call.
What happens if I stop?
You keep read access to your evidence packages for 90 days after your last paid day, long enough to close open disputes.
Start on the plan that fits this month.
Get startedConnect Swipe to Bank.
Everything your engineers need. Two ways in: connect an agent over MCP, or call the API directly. Both use the same key and reach the same services.
Point an agent at one endpoint.
Every service that is built arrives as a callable tool with its own schema. The list is generated from what actually ships, so a tool appears the moment it works and never before.
POST https://swipetobank.com/api/mcp
Authorization: Bearer stb_live_9f2c...
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/list"}{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"lookup_member",
"arguments":{"memberNumber":"STB-XXXX-XXXX-XXXX"}}}Your key on the request is your key on the call it makes. A tool can never reach anything you could not reach directly.
Or call it directly.
Create your keys
Create a live key in your dashboard. The plaintext key is shown once, then stored as a hash. Rotate it whenever you want and the old key stops working on the next request.
Start a verification
Post the person about to transact. You get a hosted link. The document never touches your servers.
POST /api/v1/identity/sessions
Authorization: Bearer stb_live_9f2c...
{"fullName":"A Customer","email":"customer@example.com",
"reference":"order_8841"}{"sessionId":"ver_01J9XQ4M","status":"REQUIRES_INPUT",
"url":"https://verify.swipetobank.com/s/01J9XQ4M"}Confirm the bank account
The customer signs in to their institution. Post the resulting token. We confirm the account owner matches the verified name.
POST /api/v1/bank/ownership
{"verificationId":"ver_01J9XQ4M","accountToken":"tok_..."}Authorize
One decision, with the checkpoint results that produced it. Pass a member number instead of a verification when the person is already registered.
POST /api/v1/swipe/authorize
{"amountCents":250000,"currency":"USD",
"verificationId":"ver_01J9XQ4M","reference":"order_8841"}Pull the evidence
Signed and append-only. Retrieve it as often as a dispute needs it, at no extra cost.
GET /api/v1/swipe/{id}/evidenceThe rest of it.
Read the catalogue
Every service and its status, public and with no key: GET /api/v1/catalog
Presence checks
Built on WebAuthn. The member device performs the biometric locally and returns a signed assertion. No biometric is ever transmitted.
When a check cannot run
The request is refused and the reason is stated. Nothing is simulated and no decision is returned on an assumption.
Terms, privacy, and security.
Terms of service
These terms govern your use of Swipe to Bank. You accept them when you create an account or call the API with a key issued to you.
What the service is
Swipe to Bank verifies the identity of the person making the swipe, confirms through the institution that the receiving bank account belongs to that person, records the binding between the card, the person, and the account, and returns an evidence package for each authorized swipe.
Swipe to Bank is a technology company. We are not a bank, we do not hold your money, and we do not move funds on your behalf. Your processor and your acquirer handle the movement itself.
What we do not promise
The service is designed to help you defend a card dispute with verified facts. Issuers and card networks decide dispute outcomes, and we do not control that decision. We make no promise about the result of any filing, about revenue, or about loss reduction. Results vary.
Your account
You are responsible for your API keys and for the activity that runs under them. Keys are shown once at creation and stored as hashes. Rotate a key as soon as you believe it is exposed.
Acceptable use
You may use the service only for swipes you are legally permitted to run. You may not submit another person's documents without their consent, resell the raw provider results, or use the service to build a competing identity dataset.
Fees
A person plan is billed once a year. A business plan is billed for the full year up front. There is no charge per check and no usage bill. Plan changes are prorated. Fees are stated in US dollars.
Ending the agreement
You may close your account at any time. We may suspend an account for non-payment or for use that breaks these terms. After your last paid day you keep read access to your evidence packages for 90 days.
Changes
We may update these terms. We will post the new version here with a new date, and material changes take effect 30 days after posting.
Contact
Write to hello@swipetobank.com with any question about these terms.
Privacy
This notice explains what Swipe to Bank holds, what our providers hold, and how long anything is kept.
What we store
For each verification we store the verified name, the verification status, the timestamps, and a reference to the provider record. For each bank link we store the institution, a masked account number, and whether the owner matched. For each swipe we store your reference, the amount, the currency, the decision, and the binding.
What we never store
We never store the identity document, the document image, the government ID number, or the date of birth. Those stay with the identity provider. We never store full card numbers or bank account numbers.
Providers
Stripe Identity performs document verification. Plaid confirms bank ownership through the institution. Cloudflare hosts the service and stores the records. Each provider processes data under its own agreement with us.
Why we hold it
We hold this data to deliver the service you bought, to produce evidence packages, to bill you, and to meet legal obligations. We do not sell personal data, and we do not use your customers' data to train models.
How long
Records are retained for seven years to cover dispute and audit windows, then deleted. You can request earlier deletion of a record where no dispute window remains open.
Your customers' rights
Your customers may ask you for access to, correction of, or deletion of their data. You are the controller of that relationship, and we act on your instruction. Write to hello@swipetobank.com and we will respond within 30 days.
Contact
Write to hello@swipetobank.com with any privacy question.
Security
This page states how the service is built and what you can verify yourself.
Account isolation
Every record carries the account that created it. Every query is scoped to that account. One account cannot read another account's rows, and there is no cross-account view in the product.
Keys
API keys are hashed at rest. The plaintext value is shown once at creation and never again. Rotation takes effect on the next request, and a revoked key stops working immediately.
Data in transit and at rest
All traffic runs over TLS. Records are stored on Cloudflare infrastructure with encryption at rest. Sensitive provider references are encrypted with a key held as a platform secret, never in the repository.
Provider posture
Identity documents stay with the identity provider. Bank credentials stay with the institution and the bank provider. Neither passes through our systems, so neither can leak from them.
Refusal over invention
When a provider adapter is absent or failing, the endpoint returns an error. The service never returns a verified status that no provider produced, and it never fabricates evidence.
Reporting a vulnerability
Write to hello@swipetobank.com with the details and a way to reproduce. We acknowledge within two business days and keep you updated until it is closed.
That page is not here.
The link may be old or mistyped. Start from the overview and you will find every page from there.
Go to the overview