How the integration works
GoHub Wallet is headless. Your brand, your login, your screens. We hold the money, the ledger and the licence, and your users never see us.
There is no hosted app to redirect to and no GoHub login for your users to create. That is the product, not a configuration of it — so the decision this page used to ask you to make no longer exists.
What that means concretely
- You authenticate your users. They sign in to you, exactly as they do today. We never see a credential of theirs and never issue them one.
- You own every screen. The wallet is a balance and a history inside your product, rendered by you. See Screens → API for the mapping.
- We are the issuer. The money, the double-entry ledger, the KYC decision and the regulatory answerability are ours. That is why signup asks for more than you might expect.
The one decision left
Whether your users get a wallet session of their own.
| Delegated session | Backend only | |
|---|---|---|
| Who calls us | Your app, with a token you asked us to mint for that user | Your backend, on its own credential |
| How you get it | POST /auth/delegated-token, naming the user | Nothing extra — you already have a machine token |
Reaches /me/* | Yes — balance, history, top-up, withdrawal | No |
| Your user can withdraw for themselves | Yes | No — you instruct every movement |
| Recorded on each movement | T1 — you asserted the user | T0 — you instructed it, no user identified |
Most integrations want the delegated session: it is what lets a user tap "withdraw" in your app without your backend brokering every call. Backend-only suits a product where the wallet is genuinely invisible — earnings accrue, and money leaves on a schedule you control.
You can use both. The choice is per request, not per tenant, and nothing is switched on or off at onboarding.
When you mint one, you are telling us who the user is and we take your word for it. That is the
point of a headless product — but it is also why the token records amr: ["tenant_delegated"], so
that a dispute years later can tell your assertion apart from an authentication we performed.
What each movement records about its authorisation
Not a permission level you are granted. A stamp written on every money row, derived from the token that authorised it, describing what we could prove at that moment. Nobody has a tier; a request is one.
| Tier | What the row records | Reached by |
|---|---|---|
| T0 | We were instructed, and know nothing about the end user | Your machine token |
| T1 | We know which user it was attributed to, not that they authenticated | A delegated token |
| T2 | The user held valid credentials with us at the time | Not reachable headless — we do not hold their credential |
| T3 | Authenticated and proved possession of a channel we hold | Step-up — not built yet |
Two consequences worth planning around:
- Nothing is gated on tier today. The stamps are recorded faithfully; no limit reads them. The tier does not restrict what you can do — it records who answers for it afterwards.
- Headless tops out at T1, by construction. Since we never authenticate your users, the strongest evidence we can hold is that you asserted them. Which means the assertion that a customer wanted a movement is yours to be able to produce.
That second point is the commercial shape of this product, and it is worth reading Money out with it in mind.
Subjects we hold nothing about
You can register a user as OPAQUE — a ledger identity with no contact details on our side. It
keeps your users' personal data entirely within your systems, which some tenants require.
The cost is that we can never reach them: no email, no future step-up, and no way for us to evidence anything about them beyond what you told us. Choose it deliberately.