Wallet & identity
LIVE · message sign-in
The server verifies a one-time Solana message signature. Wallet approval remains separate from sign-in.
Integration workflow
Inside a LamportPay payment.
One journey, distinct responsibilities. LamportPay coordinates the payment, Jupiter discovers swap routes, and Stables handles verification and the bank payout path.
SANDBOX · SANDBOX
SANDBOX: test-network assets and the payout partner's test environment. Real bank payouts and production identity verification are DISABLED pending production approval.
Jupiter routing
LIVE · read-only quotes
SOL → USDC route discovery uses mainnet market data. Mainnet swap execution is DISABLED in the sandbox build.
Stables payout
SANDBOX/SIMULATED
Sandbox quotes, hosted verification and transfer status. Production KYC and real bank payouts are DISABLED.
- 01Connect
- 02Select
- 03Quote
- 04Verify (KYC)
- 05Review
- 06Sign
- 07Processing
- 08Complete
Wallet identity & payment eligibility
Your wallet proves ownership. Verification opens the next step.
Two distinct checks: LamportPay verifies wallet control; Stables handles hosted identity verification.
LIVE · MESSAGE SIGN-IN
01
Prove wallet ownership
Connect a Solana wallet and sign a plain-text sign-in message. This proves control of the wallet—not your legal identity. It is not a transaction and does not move funds.
No custody. No identity-document collection.
Your wallet keeps its keys. LamportPay coordinates quotes, recipient checks and status; Stables provides the single-use deposit address and payout infrastructure.
A sandbox completion is not production KYC.
The app can retain verification from a completed payment, avoiding repeat prompts. Current completions are sandbox records only; production identity verification and real fiat payouts remain DISABLED.
From request to receipt
Current sandbox behavior, alongside the production path that remains disabled.
01
Wallet sign-in
LIVELamportPay + Solana wallet
Today · sandbox
Verify the signed message, its origin and freshness before linking the wallet to the customer account.
Production · disabled
The same wallet-first identity model; no private key or seed phrase is accepted.
02
Amount & quote
SANDBOX/SIMULATED · payout quoteStables · Jupiter when needed
Today · sandbox
Get a Stables sandbox quote before verification. SOL estimates use a read-only Jupiter route. Show the LamportPay fee and separate provider costs.
Production · disabled
An approved Stables production quote determines corridor support, pricing and customer limits.
03
Payout details
SANDBOX/SIMULATEDStables
Today · sandbox
Validate the bank fields Stables requires. Own-account holder names come from the verified record; beneficiaries require their details and a payment purpose.
Production · disabled
The verified sender can request an own-account or beneficiary bank payout, subject to partner checks.
04
Verification & review
SANDBOX/SIMULATED · KYCStables hosted page
Today · sandbox
Complete any required sandbox verification with Stables, then review the recipient, quote and costs. LamportPay does not collect identity documents.
Production · disabled
Production KYC is DISABLED until approval. Transfers require a verified Stables customer.
05
Wallet approval
SANDBOX/SIMULATEDSolana test network
Today · sandbox
Sign a real test-network memo transaction that moves no funds. The server checks the signer, memo, freshness and success before simulating the sandbox deposit.
Production · disabled
DISABLED: user-signed funding to Stables’ single-use deposit address, with any applicable fee transfer and settlement checks.
06
Status & receipt
SANDBOX/SIMULATEDStables · signed webhooks
Today · sandbox
Signed webhooks and reconciliation follow Stables’ sandbox transfer status. Processing is not completion; a receipt updates only when the reported status changes.
Production · disabled
The same provider-authoritative status model, with live bank settlement only after production approval.
Implemented request sequence
These are existing app endpoints, not a public third-party API contract. Payment actions require a signed-in customer and server-side checks; an endpoint’s existence does not enable production payouts.
| Step | Method | Endpoint |
|---|---|---|
| Sign in | POST | /api/wallet/sign-in |
| Estimate | POST | /api/quote/estimate |
| Create payment | POST | /api/payments |
| Get quote | POST | /api/payments/:id/quote |
| Check bank details | POST | /api/payments/:id/payout-details |
| Verification status / link | GET / POST | /api/kyc |
| Prepare transfer | POST | /api/payments/:id/transfer |
| Verify test approval | POST | /api/payments/:id/test-payment |
| Read status & receipt | GET | /api/payments/:id |
Stables events arrive at /api/public/stables-webhook. Signed events and periodic reconciliation keep the stored status aligned with Stables.
Admin refresh checks an existing transfer’s status. It does not send funds, create a transfer or simulate a deposit.
Further reading
All articles- Web3 payment railsWeb3 payment rails: the reference architectureA component-by-component architecture for a Web3 payment rail — wallet layer, routing, verification, state machine, payout integration, and the observability that holds it together.Read
- SolanaBuilding payments on Solana: a developer's checklistCommitment levels, transaction verification, blockhash expiry, token accounts and RPC reliability — the Solana specifics that decide whether a payment integration is trustworthy.Read
- Crypto-to-fiatCrypto-to-fiat payments: how the money actually movesA step-by-step breakdown of how a crypto payment becomes local currency in a recipient's bank account, and which party is responsible for each leg.Read