LamportPay Docs

Architecture

Application

TanStack Start, React, Vite and Tailwind CSS. Separate marketing, wallet-connected payment app and protected admin experiences.

Payment orchestration

Server functions and API routes coordinate quotes, bank-field validation, verification gates, transfer references and payment tracking.

Wallet & settlement asset

Solana wallet signatures and transaction verification. USDC is enabled; USDT payment support remains DISABLED. This build runs on a Solana test network.

Conversion · LIVE read-only

Jupiter supplies eligible Solana-to-USDC market quotes. The sandbox build blocks mainnet order and execution; USDC payments skip the swap.

Payout · SANDBOX/SIMULATED

Stables' test environment provides quotes, hosted verification, checked bank details and transfer status. Production payouts and KYC are DISABLED.

Runtime & hosting

Node.js and TypeScript on the server. Managed cloud hosting today, with a planned move to AWS as volume grows.

Engineering

Built from scratch by our in-house team. AI tools (ChatGPT, Claude, Lovable) assist with support, automation, marketing and coding; the team designs, reviews and owns the code.

Security roadmap

Core controls are in place (access rules, signed webhooks, audit log, rate limits, scans). An independent audit, penetration testing and hardening form the next funded phase before go-live.

Data & operations

SQL / PostgreSQL stores payment records, identity links, verification status, timeline events and append-only admin audit records—not customer balances.

Identity & access

Quote-first payment sequence

1. Connect. Connect your Solana wallet and sign a plain-text message to sign in. This is not a payment transaction.
2. Select. Choose your amount, destination country and payout currency. USDC is the enabled settlement currency; SOL routing is available when supported by your wallet.
3. Quote. See the estimated local-currency amount, LamportPay fee and separate partner costs before identity verification. Quotes expire and may need refreshing.
4. Verify (KYC). Complete identity verification (KYC) on Stables’ hosted page. LamportPay keeps only the verification link and status—never your identity documents. Verified once, your wallet skips this step on later payments.
5. Review. Bank details are checked with Stables. Review the recipient, amount, LamportPay fee and partner costs before you approve.
6. Sign. Approve in your wallet. In the sandbox build, you sign a test-network memo transaction that moves no funds—not a mainnet deposit or swap.
7. Processing. The app simulates a sandbox deposit and follows the transfer status reported by Stables. Some sandbox destinations can remain processing.
8. Complete. When Stables reports completion, the timeline and receipt update. A sandbox receipt is a demonstration record, not evidence of a real bank payout.

A transfer is created only for a verified sender. Own-account payouts use the verified holder name; beneficiary payouts require the beneficiary's name, type and an appropriate payment purpose. Bank details are validated by Stables in either case.

Amounts & costs

Payment arithmetic uses integer minor units rather than floating-point amounts. LamportPay's fee is taken from the user's sent total once; optional minimum and maximum fee bounds are off by default. The payment record keeps the applicable fee rule. The sandbox build collects no real revenue.

LamportPay fee

One fee, taken out of the total you send—not an extra conversion fee plus a swap fee. The app shows the fee amount before approval.

Payout partner fee

Stables costs are quoted separately. They are not included in LamportPay’s fee.

Swap & network costs

Any Jupiter swap costs, price impact and Solana network fees are separate. The sandbox build does not execute mainnet swaps or move payment funds.

Country-to-currency defaults are reference data, not supported-corridor guarantees. Stables quotes establish country/currency availability, bank-field validation checks recipient details, and configured limits are enforced by the payment app.

Status synchronization & safeguards

• Stables transfer status is authoritative. Signed webhooks are the primary update path; live status reads and background reconciliation recover missed events without moving progress backwards.
• Provider writes carry idempotency keys. Webhooks are stored before processing; invalid signatures are refused. A temporary provider error preserves the stored payment status.
• The sandbox build verifies memo signer, payment reference, transaction success, freshness and non-reuse before simulating a deposit. A wallet signature alone does not mark a payout complete.
• Rate limits and emergency payment controls restrict payment actions. Admin audit records are append-only; the admin payout queue refreshes status only, never creates a transfer or simulates a deposit.
• Travel Rule requirements are payment requirements. Refunds, compliance holds needing operational follow-up and manual review are handled through operations cases, not invented settlement outcomes.

Some sandbox destinations can remain processing. Receipts update when Stables reports completion; a sandbox receipt does not prove a real bank payout. These controls do not constitute a completed security certification.

Integration boundaries