Money in
Payment links, a hosted page, your own checkout, instant bank rails, cards.
Product
Four areas, one set of numbers. Every screen carries two lenses, so a merchant sees their business and nothing behind it.
The four areas
These are not four stages a payment passes through in order. They are four parts of the board, and any of them can be the one you are looking at when the question arrives.
After a payment
Refunds with approvals, disputes with a lifecycle, evidence and outcomes.
Balances and reports
What you hold, what settles when, the ledger behind it, and exports.
The two lenses
This is the idea the whole product is built around.
Everything else follows from it.
THE OPERATOR LENS
The people running the service
The full picture. Every merchant, the cost side, the routing, the reconciliation and the margin.
THE MERCHANT LENS
A business taking payments
Their own account. Their fees, their volume, their balances, their settlements, their customers.
The hidden fields are stripped in one place, so a new screen inherits the rule by existing.
Control
Access questions get answered by the back end every time.
A browser asking nicely for
somebody else's data gets nowhere.
| The control | What it means |
|---|---|
| The account you reach | Decided from your signed session, never from the request. Naming another account in a request changes nothing. |
| The fields you receive | One layer removes the operator only fields from every response before it leaves. |
| The areas you see | Each area is switched on per merchant. An area that is off answers with a clear refusal. |
| The sensitive actions | Some actions ask you to prove who you are again before they run. |
| Repeated requests | A write that arrives twice happens once, so a retry stays safe. |
| The record of it | Changes, sign ins on behalf of somebody, and access to personal data all leave a trail. |
Thirty minutes. We open the screens and follow one payment from arrival to settlement.
hello@orchespay.com