Solutions
Three proposed workflows for moving money across borders.
These are the first routes we expect to build. They are examples of how the product could work, not live services, and the details will change as we learn from early conversations.
Workflow 01
Supplier payments
The problem
Paying overseas suppliers often means handoffs between banks, intermediaries and internal teams. It can be hard to say where a payment is, and the records end up scattered across inboxes and spreadsheets.
Illustrative example
A manufacturer approves an invoice from a component supplier abroad. Finance creates the payment, follows it through funding, settlement and delivery, then exports the references to match against the ledger.
A hypothetical scenario, not a customer story.
Proposed workflow
- 01
Approve the invoice
Review the supplier details and amount, with approvals where required.
- 02
Create the instruction
Specify the recipient and amount. A payment record opens with a reference.
- 03
Follow the voyage
Track funding, settlement and recipient delivery as separate, labelled stages.
- 04
Reconcile
Match references to the invoice and export the record for finance.
Workflow 02
Contractor and team payouts
The problem
Paying contractors across countries means many recipients, different payout preferences and repetitive manual work. Each payment is small, but the operational overhead adds up.
Illustrative example
A design studio pays a monthly batch to contractors in several countries. Each recipient has a recorded payout preference, and the studio can see which payments are still in progress.
A hypothetical scenario, not a customer story.
Proposed workflow
- 01
Prepare the batch
Create or import a list of recipients and amounts.
- 02
Review and approve
Check the batch as a whole, then approve it before funding.
- 03
Deliver per recipient
Each recipient follows their own route, with status shown individually.
- 04
Export records
Keep one consistent payment record per recipient for finance and tax teams.
Workflow 03
Embedded platform payments
The problem
Platforms that pay sellers, creators or partners internationally have to assemble and maintain payout infrastructure that is not their core product, while still showing users clear status.
Illustrative example
A marketplace triggers a payout when an order completes. Its own interface shows the payout status, powered by status updates from the payment record.
A hypothetical scenario, not a customer story.
Proposed workflow
- 01
Connect
Integrate through a planned API and configure supported providers.
- 02
Trigger payouts
Create payouts from platform events such as completed orders.
- 03
Show status
Surface stage-by-stage status inside your own product.
- 04
Reconcile
Match every payout to platform records with consistent references.
Across every workflow
The same record underneath.
- 01
Clear payment tracking
Every payment moves through labelled stages, so teams can tell whether funds are being checked, settling on a network or waiting on a payout provider.
- 02
Vendor payment workflows
Approvals, recipient details and amounts live in one workflow, replacing the usual trail of emails and spreadsheets.
- 03
Unified payment records
Instruction, funding, settlement and delivery references are kept together, ready to match against invoices and ledgers.
Fees, timing, eligibility and availability would depend on the funding, network and payout providers involved and on the destination. We do not promise instant bank payouts or one-to-one redemption of any stablecoin.
Early access
Which of these looks like your payments?
Early access is not open yet. Tell us what you pay, where it goes and what is hardest about it, and we will use it to decide what to build first.