Solvexa
How it works

See how we built our crypto processing platform

The whole path in one place: how a payment arrives, how it gets screened, how it settles, and how your team connects to it. Predictable behaviour and a record you can audit are what we designed for, so the flow is written out below rather than summarised in a diagram.

Built around how businesses actually get paid

Most crypto payment problems are not technical. They show up as a customer who paid the wrong amount, a payout stuck behind an approval nobody owns, or a month-end where the ledger and the chain disagree.

We take on the acceptance flow, the payout flow, and the reconciliation between them. Screening runs inside that path rather than beside it, so the compliance record is a by-product of normal operation instead of a separate project.

Money in

Accepting payments

A checkout your customers can complete without instructions, and a settlement record your finance team can close the month with.

Customers pay through a hosted checkout page or through your own interface over the API. Each order gets its own address, so incoming funds map to an invoice without manual matching. The rate is fixed when the customer commits, and the exposure between that moment and confirmation sits with us rather than with you.

  • Hosted checkout or direct API
  • A dedicated address per order
  • Status pushed over webhooks
  • Underpayments and late arrivals handled as normal cases
Money out

Sending payouts

Payouts to suppliers, partners and counterparties, one at a time or in batches, with approvals that leave a trail.

Batch releases

Batch files let you release a supplier run or a partner settlement in one operation instead of hundreds.

Approval steps

A payout above a threshold you set can require a second person. Each release records who approved it, when, and against which screening result.

Screened before release

Destination addresses are scored before funds move. An address that fails is held for review rather than sent and regretted.

Money settled

Balances that reconcile, statements you can hand over

Reconciliation runs continuously against on-chain state, so the figure in your dashboard is the figure you can act on.

01

Settlement in EUR and USD

Revenue can leave the crypto leg through partner channels and land in your bank account on a schedule you define.

02

Exports your accounting accepts

Statements export in the formats accounting systems read, by period, asset or counterparty.

03

Evidence attached

Every report carries the underlying transaction detail, including screening outcomes. When a bank asks how a payment cleared, the answer is already in the file.

What you see day to day

Six screens cover the whole operation. Access is per person, with roles and approval thresholds set by you.

Every payment and payout

Transactions, with status and screening result

Pending and available

Balances per asset

Submission to release

Payout queue and history

By period or counterparty

Statements and exports

Keys, webhooks, sandbox

API access

Roles and thresholds

Team and permissions

Four ways to connect

Most merchants start with hosted checkout and move to the API once the flow is proven. There is no penalty for changing your mind.

01

Hosted checkout

Redirect the customer to a payment page we host and maintain. The fastest route to a working flow, with no payment interface to build and nothing sensitive touching your servers.

02

REST API

Build the payment experience inside your own product. Create orders, quote rates, read status and submit payouts programmatically.

03 Signed

Webhooks

Payment status, payout status and screening outcomes pushed to your endpoint as they change, with signed payloads and retries.

04

CMS plugins

Drop-in modules for common e-commerce platforms when the store is standard and the timeline is short. The list of supported platforms is confirmed during onboarding.

For your engineering team

Everything above runs on one API

Hosted checkout and the plugins are the fast path. Underneath, the checkout, the payout queue and the dashboard all call the same REST API, so nothing on this page is a shortcut around it.

Orders and quotes

Create an order, quote a rate and read its status without leaving your own product.

Payouts

Submit single or batch payouts programmatically, under the same approval and screening rules as the dashboard.

Signed webhooks

Every status change, payment, payout and screening outcome, pushed to your endpoint with a signed, retried payload.

Sandbox first

A fully isolated environment with its own keys and data, so your team can build and test before anything touches a real balance.

Want a sandbox and test access? Send us a note and we will set up sandbox credentials so your team can build and test the integration before anything is signed. Request sandbox access.

Getting started

From first call to first payment

  1. 01

    We map your payment model

    Volumes, assets, customer geography, payout obligations, and whatever your current setup already constrains. This is a conversation, not a form.

  2. 02

    We shape the setup

    Integration method, payout logic, screening thresholds, settlement schedule and reporting. You get the specification before anyone writes code.

  3. 03

    We connect and test

    Sandbox credentials first. Your team builds against test flows, we verify webhooks, reconciliation and edge cases together, then production keys are issued.

  4. 04 Ongoing

    We stay on after launch

    Monitoring, a named operations contact, and adjustments as volume grows or requirements shift.

What we need to start

Nothing here is a surprise later. If something on the left is difficult, say so in the first message and we will work out what is possible.

From you

  • Corporate documents and ownership structure
  • A description of the business model behind the payment volume
  • Expected volumes, assets and customer geography
  • A technical contact and a callback endpoint
  • Payout destinations, if payouts are in scope

From us

  • Sandbox credentials and API documentation
  • A named integration engineer for the duration of the build
  • A written specification of the agreed setup
  • Screening thresholds and escalation rules, in writing
  • A timeline you can plan around, once we have seen the flow

Security of the integration

Four things that are not configurable

Signed requests

Every API call is authenticated and every webhook payload is signed, so your system can verify what it receives.

Separate environments

Sandbox and production are fully isolated, with separate keys and separate data.

Scoped keys

Keys carry only the permissions they need, and can be rotated or revoked without taking the integration down.

Access controls

IP allowlisting on request, role-based access in the dashboard, and approval thresholds per user.

How the service is run

What you can hold us to

Availability

Watched, not assumed

The gateway is monitored continuously and incidents are communicated rather than discovered. Availability targets are agreed per contract.

Support

Named people

A named integration engineer during onboarding and a named operations contact afterwards, not a rotating queue. Escalation paths are written down before you need them.

Room to grow

Changes are ordinary work

New assets, new networks, new payout routes and threshold changes are handled as routine, not as a new project.

On request

Commercial terms

Pricing depends on volume, asset mix and payment model. We quote after reviewing your flow, in writing, with no setup fee before the specification is agreed.

Questions merchants ask first

The four that come up in every technical call.

How long does integration take?

It depends on the method and on how quickly onboarding documents come back. Hosted checkout is the fastest because there is no payment interface to build. We give a timeline in writing once we have seen your setup, and we do not quote one before that.

Can we test before signing anything?

Yes. Sandbox credentials come before production keys, and the sandbox is fully isolated with its own keys and data, so nothing you do there touches a real balance.

What happens if a webhook fails to reach us?

Deliveries are retried, and every payload is signed so you can verify it when it arrives. Status is also readable over the API, so a missed webhook never leaves your system out of sync permanently.

Can we start with acceptance and add payouts later?

Yes, and most merchants do. Adding payouts later is a configuration change plus the approval rules you want, not a new integration.

Next step

Tell us how you get paid today

Send over your payment model and volumes. We will come back with a setup, a timeline and commercial terms.

An NDA is available on request before you share anything sensitive.