Payment authorization & evidence layer · built on ORBIS.ID
Scan one code at any checkout. Everything happens on your own phone: you see the shop's real legal name and the exact amount, you choose how to pay, and one fingerprint or face signs it. Your card, your key and your biometrics never leave the device. You keep a receipt no one can alter.
A card authorization proves a card was presented. It never proves a specific person agreed to specific terms — which is why merchants lose most disputes they contest. ORBPAY replaces the argument with a signature: identity, entitlement and the exact amount, signed once on the customer's device, delivered to your backend, charged through the PSP you already use.
How a purchase actually happens
Step through the ceremony. Watch what crosses each boundary, and what never does. The red zone is the regulated funds path: money moves there, between the merchant and the merchant’s own processor. ORBPAY is never inside it.
Custody, made visible
The question every payments company gets asked is “what happens if you are breached?” Our answer is structural: there is nothing to take. Money, card details, biometrics and personal data each live with exactly one party — and it is never ORBPAY.
Moves once, from your bank to the merchant, through the processor the merchant already has a contract with. ORBPAY has no PSP keys, no gateway calls and no account — the build fails if any ORBPAY code path can reach a payment endpoint.
no-unported-network — the phone may only talk to three host classes: the static registry (read), the merchant’s channel endpoint, and the merchant’s PSP. Nothing else compiles.Inside ORBLINK · Wallet › ORBPAY
These are the actual ORBPAY screens from the ORBLINK app. The offer sheet cannot display a value from a web page — its inputs are typed so that only a verified, merchant-signed offer can reach it. What you see is, literally, what you sign.
At the counter
A bottle of wine at a corner shop today means two rituals: show an ID, then tap a card. With ORBPAY the terminal shows one code. Your phone proves “over 21” — not your birthdate, not your name — and pays, in the same signature. Press play.
Why people use it
Why businesses adopt it
Generated inside the Secure Enclave or StrongBox, never exportable — not by you, not by us, not by a court order served on ORBPAY. A stolen, unlocked phone can’t sign: every signature needs a fresh face or finger.
The phone resolves the merchant from a signed public registry and displays “Demo Bistro”, its verified entity, not whatever a page or a sticker says. First-time merchants are flagged before the sensor is ever offered.
Nothing from the web page is ever displayed or signed — only the merchant-signed offer pulled over an encrypted channel. A hacked checkout showing $47.30 while charging $4,730 simply cannot happen.
A tip, a minibar, a renewal at a new price — each arrives as a request you approve or decline. Silent charges and surprise renewals are impossible by construction, not by policy.
Your KYC passport is issued once by DIDit and lives in your wallet. Merchants receive a single yes/no fact, never the document. No more uploading your ID to every shop that sells wine or vapes.
Three signatures sealed together — the shop’s offer, your acceptance, the processor’s authorisation. You can verify it on your phone in airplane mode, years later. Nobody, including ORBPAY, can edit it.
A hardware-bound, biometric-gated signature over the exact terms is the strongest dispute evidence that exists. “I didn’t recognise it” meets a record of who agreed, to what, when.
Stop paying an identity vendor per check and storing the results. The mandate carries age_over_21: true from a DIDit-issued credential, cryptographically inseparable from the payment authorisation.
No card number, name or ID ever passes through your checkout. Web-skimming has nothing to skim, and PCI DSS 4.0.1 §6.4.3 / §11.6.1 script monitoring stops being your problem on that page.
PCI DSS 4.0.1 mandatory since 31 Mar 2025The phone tokenises the customer’s card directly with your processor using your publishable key. Your backend charges as it does today. No migration, no new money relationship, no re-plumbing.
Your ORBPAY code carries no URL. A counterfeit sticker or injected QR cannot make a phone contact anything the signed registry does not name. Your brand stops being a phishing vector.
Every follow-up produces its own signed record chained to the original. More signatures, never looser ones: each is a two-second push to a device you already paired.
A merchant doing $1m/month in high-risk card-not-present volume carries roughly $62,800 a month across chargebacks and fraud, the high-risk processing premium, an age or identity vendor, and payment-page PCI obligations. ORBPAY costs on the order of $1,000. A ten percent reduction pays for it six times over — and verification of every record is free, forever.
Anatomy of the evidence
Hover or tap any field. The composite mandate binds identity, merchant, amount, order and instrument so they cannot be separated. The sealed record adds the merchant’s offer and the processor’s authorisation — three independent signatures, one immutable artifact, held by both parties.
This is how ledgers have worked for five hundred years: an invoice is never amended, a credit note is issued. Auditors and ERP systems understand it instantly — and every link is verifiable without ORBPAY.
Try to break it
Every attack below is a switch in our reference test merchant, and each must be rejected for the build to pass. Choose one to see how the phone responds — the rejection reasons are the real enumerated codes, not marketing.
Where ORBPAY sits
Apple has the key but splits identity and payment into separate APIs. Google’s AP2 has the signed mandate but no identity binding and a coalition gate. W3C SPC binds the amount but trusts the page and stops at Chromium. BankID has the signature but stops at the border. Each holds at most two cells.
| System | Identity in same signature | Renders only signed data | Works outside the browser | No scheme gate | Portable receipt | Request-only charging | No licence needed | Any rail |
|---|---|---|---|---|---|---|---|---|
| ORBPAY | ||||||||
| W3C Secure Payment Confirmation | ||||||||
| Apple Pay + Verify with Wallet | ||||||||
| Google Pay + Wallet ID | ||||||||
| Google AP2 (agentic mandates) | ||||||||
| EMV 3DS + delegated authentication | ||||||||
| Pix · UPI · Swish · BLIK · Wero | ||||||||
| BankID · itsme · MitID | ||||||||
| Yoti · Persona · Incode · Jumio |
For businesses · integration
Your web page becomes a display surface — it shows a code and, later, “paid”. Your backend does three things it is already good at: sign an order, accept a document, call the processor it has a contract with. No customer data ever touches your front end.
An organisation account is opened by a real, KYC’d person holding an ORBLINK key. Your legal name and offer-signing key go into the signed public registry. That is what the phone displays.
Items, tax, shipping, options, the final amount, your PSP’s publishable key — signed with a key in your HSM. The checkout widget renders the engagement token as a QR, NFC or deep link.
Our SDK verifies every check: your offer digest, the recomputed amount, nonce and session, the customer’s credential binding, replay. Any failure is a signed decline — no gateway call is made.
Create the PaymentIntent for exactly the mandated amount with the single-use token the phone minted at your PSP. On authorisation, seal the record and return it. Verification is free for everyone, forever.
// checkout page · display only · nothing sensitive ever renders here const session = await fetch("/orbpay/session", { method: "POST", body: cart }).then(r => r.json()); orbpay.widget("#pay", { token: session.engagement_token }); // ORBPAY1.<ref + channel key> — no amount, no URL // backend · your HSM signs; your PSP charges; ORBPAY receives nothing but a hashed metering event const offer = signer.signOffer({ mid, ref, amount: { minor: 8420, currency: "USD" }, lines, required_claims: ["age_over_21"], psp: { provider: "stripe", publishable_key } }); channel.onMandate(async ({ mandate, instrument_payload }) => { const ok = orbpay.verifyMandate(mandate, { offer, registrySnapshot }); // offline-capable; every check enumerated if (!ok.pass) return channel.decline(ok.reason); const pi = await stripe.paymentIntents.create({ amount: 8420, currency: "usd", payment_method: instrument_payload.psp_token, confirm: true }); return channel.seal(signer.sealRecord({ offer, mandate, authorization: pi })); // three signatures, one immutable record });
Card first (Stripe, then Adyen). Bank transfer, Pix, UPI, stablecoin — the mandate is identical; rail is configuration. ORBPAY competes with no rail and can authorise onto all of them.
Web checkout, in-app, POS terminal, kiosk, invoice, agent-to-merchant. The engagement token is modality-agnostic: QR, NFC, BLE or deep link carry the same payload.
Anyone — an auditor, a bank, a regulator, the customer — verifies a record against static signed files on a CDN. A total ORBPAY outage does not stop a single verification.
ORBPAY’s architecture is complete and its artifact formats are defined; the build is phase-gated on ORBIS.ID and ORBLINK, which are close to release. Capabilities on this page are described as specified, not as shipped. The screens above are the ORBLINK shell running in sandbox mode; the same “What’s real” register that labels each capability inside the app labels every claim here. External figures are dated and sourced. ORBPAY is a technical service provider by design — it never initiates a payment or holds funds — a reading we consider favourable, not adjudicated, and one we will confirm with formal opinions before scale. Structure: ORBPAY is a separate company with strategic relationships to ORBIS.ID and ORBLINK. Nothing here is investment, legal or financial advice.