New to SpherePay? Start with How it works and Concepts. Know your business outcome but not your flow type? Read this page first, then Solutions.
How to use this section
Confirm scoping inputs
Work through Before you pick a guide with your SpherePay representative — parties, rails, volume, and transfer model.
Route to a guide and pattern
Use Route by discovery outcome to pick First-Party or Third-Party Flows and the pattern inside that guide.
Validate before engineering
Complete the guide’s scoping output, kickoff list, and blocker checks before writing integration code.
Go deeper where needed
Follow links into Concepts, Solutions, and API Reference for object definitions, business examples, and payloads.
What these guides are for
| Section | Use it to… |
|---|---|
| Implementation Guides (this section) | Route to a build path, validate scoping, and know what to send Sphere before kickoff |
| Concepts | Learn what each object means — customers, transfers, automation, rails |
| Solutions | See how primitives combine for a business outcome — treasury, payroll, trading |
| API Reference | Implement request/response details for a specific endpoint |
Before you pick a guide
Confirm these inputs with your SpherePay representative during or immediately after discovery:- Who owns the funds at each step
- Customer of record — who SpherePay must onboard and verify
- Sender and beneficiary — may differ from the customer of record
- Platform role — whether your platform is in the flow of funds
- Downstream users — businesses, consumers, or both
- Fiat currency and rail — see Supported rails
- Stablecoin and network — see Supported assets
- Transfer model — one-off API transfers vs reusable deposit/cash-out instructions
- Balance model — movement/conversion only vs fiat balance holding
- Volume — expected monthly volume, average and maximum transaction size
Route by discovery outcome
| After discovery, you know… | Start here | Pattern |
|---|---|---|
| The same legal entity owns both the source and destination | First-Party Flows | — |
| Each on-ramp/off-ramp is initiated explicitly via API | First-Party Flows | One-off transfer |
| Reusable fiat deposit instructions into the customer’s own wallet | First-Party Flows | Onramper Account |
| Reusable stablecoin-to-fiat cash-out to the customer’s own bank account | First-Party Flows | Offloader Wallet |
| A business pays a supplier, vendor, contractor, or other third party | Third-Party Flows | Business pays supplier |
| A platform enables its business customers to move funds | Third-Party Flows | Platform serves business customers |
| A bank or fintech embeds ramps for many end users | Third-Party Flows | Bank or fintech serves consumers |
Pick a guide
First-Party Flows
Same legal entity owns source and destination — one-off transfers, Onramper Accounts, and Offloader Wallets.
Third-Party Flows
Different parties or platform-mediated flows — supplier payouts, platform B2B, and consumer embed paths.
First-party or third-party?
If the routing table above does not match cleanly, use this fork:| Flow type | Route when | Example |
|---|---|---|
| First-party | The same legal entity owns the source and destination | Company bank account → same company’s wallet |
| Third-party | Sender, beneficiary, or customer of record are different entities, or a platform serves downstream users | Company wallet → supplier bank account |
Map to Solutions
Implementation Guides define how to build. Solutions define what business outcome you are shipping. Use both:Treasury management
First-party treasury on-ramp/off-ramp — pair with First-Party Flows.
Payment acceptance
Platform fiat acceptance — often Third-Party Flows or Onramper pattern.
Payroll
Third-party disbursements — pair with Third-Party Flows.
Cross-border trade finance
Supplier and invoice settlement — pair with Third-Party Flows.