Talk to us

In active development · payvan.net

Payments,
engineered end to end.

PayVAN is a payment platform built from scratch — hosted checkout, card acquiring with 3-D Secure 2, payouts, recurring, crypto and smart routing. One signed API, one dashboard, and one very stubborn rule: we never report an outcome the bank hasn't confirmed.

Become a launch partner See the API
  • 1API contract, one set of docs
  • 4checkout languages out of the box
  • 0card data on your servers
Hosted checkoutCard acquiring3-D Secure 2Payouts RecurringApple Pay & Google PayPayment linksSmart routingSigned webhooks Crypto & stablecoinsMerchant dashboardSandbox with a test bank

The platform

Everything a payment needs, in one place

No stitching together a gateway, a 3-DS vendor, a payout provider, a crypto processor and a reporting tool. PayVAN is one contour: the checkout, the processing core, the routing, the ledger and the dashboard were designed together.

Hosted checkout

Create a payment without touching card data. We host the form — your theme, four languages, light and dark, mobile first — and hand the payer back to you with a result.

3-D Secure 2

The whole flow lives on our side: frictionless and challenge, every challenge screen shape, browser and merchant-initiated flows. The outcome of a challenge doesn't depend on whether the browser made it back.

Card acquiring

Single payments, blocks and captures, partial refunds, cancellations, each payment with all its operations in one read. Every mutation is idempotent and replay-safe.

Payouts

Push money out to cards against a payout balance you can read at any time. More than the balance and it is refused up front; what is accepted gets a terminal status only when the bank actually says what happened.

Subscriptions

Scheduled charges on a saved card: pause, resume, change the amount, cancel — by subscription id, with no card involved. Terms of the offer and a cycle limit are part of the subscription, not of your cron job.

Payment links

An invoice page in one request: fixed or free amount, the payer fields you need, a code you can send anywhere. Revoke it, track what it collected, reuse it.

Smart routing

Many acquirers behind one contract. Route by BIN, currency, country, cost or provider health, and move traffic without shipping code on your side.

Merchant dashboard

Operations, balances, reports, payment links, your team and their roles. Configuration lives in one place and reaches processing over a bus, so what the dashboard shows is what the gateway actually applies.

dash.payvan.net

Webhooks that arrive

Signed, deduplicated by id and retried twelve times with growing backoff when your endpoint is having a bad afternoon. They can land out of order, so a status call stays the tiebreaker — we say that in the docs instead of letting you find out.

Apple Pay & Google Pay

Wallet tokens go to the same endpoints as a card — one extra field, no separate integration. On our checkout they appear by themselves where the payer's device supports them.

Customers & KYC

One customer record across your shops, with the verification you have already done declared to us — at payment time or later, when it finishes. Routing can use it.

Status you can reconcile

Look an operation up by transaction, by your own order id, or by period. The ledger answers, not a cache — so the figure in your books and the figure in ours are the same.

Crypto, without crypto accounting

Payers who hold USDT and other coins can settle with them, while you price, invoice and reconcile in fiat exactly as before. The rate is fixed before the payment starts, so the amount that reaches your balance is the amount you asked for — no wallets to run, no volatility to hedge, no second set of books.

  • USDT and major coins
  • Rate locked up front
  • Your balance stays in fiat
  • Same API, same webhooks

One integration

Integrate once.
Change rails whenever you like.

Acquirers come and go, terms change, a provider has a bad week. That is our problem, not your release cycle. You keep talking to one API contract while traffic moves underneath it.

  • Provider adapters behind a single internal contract
  • Per-merchant rules: BIN, currency, country, amount, method
  • Failover when a provider degrades, with the decision recorded
  • Cost and conversion visible per route, not per invoice
Your backend
Card acquirers
Local methods
Payout rails
Wallets & transfers
PayVAN corerouting · fraud checks · ledger · workflows

For developers

An API you can read in an afternoon

REST over JSON, one signature scheme, a request id that makes retries safe, and a sandbox talking to an emulated bank — including a full 3-D Secure 2 flow you can drive from tests. The whole contract is public, with an OpenAPI file you can generate a client from.

Read the docs API reference 
// Create a payment session — no card data ever reaches you.
POST https://pay.payvan.net/v1/checkout/sessions
X-SHOP-ID: 1042
X-REQUEST-ID: 6f1c2a48-4f6e-4a1e-9a2c-1c8c9a2f9e01
X-REQUEST-TIMESTAMP: 1791181232
X-REQUEST-SIGNATURE: v1=<hex HMAC-SHA256 of the canonical string>

{
  "PaymentType":  "Pay",
  "Amount":       "49.00",
  "Currency":     "USD",
  "OrderId":      "order-1043",
  "Description":  "Pro plan, November",
  "ExtraData":    {
    "SuccessUrl": "https://shop.example/paid",
    "DeclineUrl": "https://shop.example/failed",
    "CancelUrl":  "https://shop.example/cart"
  },
  "CustomerInfo": { "Language": "en", "Email": "[email protected]" }
}

// 201 Created — send the payer to CheckoutUrl, we take it from there.
{
  "SessionId":   "6d0f3c1e-2a4b-4c1d-9e5f-0a7b8c9d0e1f",
  "CheckoutUrl": "https://pay.payvan.net/pay/6d0f3c1e-2a4b-4c1d-9e5f-0a7b8c9d0e1f",
  "ExpiresAt":   "2026-10-12T12:40:00Z"
}
Idempotent by default

Retry with the same X-REQUEST-ID and you get the first answer back, for 24 hours — never a second charge. Reuse it for a different request and we say so, loudly.

Signed, with a clock

Every request carries an HMAC over method, path, shop, request id, timestamp and a hash of the body, valid ±5 minutes. Rotating the secret keeps both keys alive, so nothing breaks mid-rotation.

A sandbox that lies to no one

A bank emulator on separate hosts and keys. You pick the scenario with the test card's CVC and expiry month: declines, timeouts, every 3-D Secure 2 path — so your error branches get tested too.

Docs, not a swagger dump

docs.payvan.net is a written guide plus an OpenAPI 3.1 reference; openapi.yaml generates your client, and signing examples in Python and Node are there to paste.

Security

Card data stays where it belongs

Our checkout captures the card in isolated fields served from our own card domain. Six inputs are inside the card perimeter — not your page, not your servers, not your logs.

  • Hosted card fields on a dedicated, minimal-surface origin
  • PAN masked in every log line the platform writes
  • HMAC-SHA256 request signing, replay-safe request ids
  • Money state changes only through audited stored procedures
  • One trace id from the API call to the bank's response
  • Everything in UTC, everywhere, with no local-time surprises

Invariants we refuse to break

No guessed outcomes

If the bank hasn't told us what happened, the operation stays RESULT_UNKNOWN until it does. We would rather show you an unfinished payment than a wrong one.

Durable by construction

Every operation is a workflow that survives restarts and retries only what is safe to retry. Deploys don't lose payments.

Everything is reconstructable

Each state transition is recorded with who, when and why. Support answers questions from the record, not from a guess.

Where we are

Honest roadmap

PayVAN isn't live yet — and we would rather say so than dress a prototype up as a bank. Here is exactly what stands today.

  1. Running

    The contour and the docs

    Gateway, transaction core, hosted checkout, webhooks and an emulated bank with a complete 3-D Secure 2 flow, working end to end in our test environment — and the whole merchant API written up at docs.payvan.net.

  2. In build

    Dashboard, payouts, crypto

    Merchant cabinet with roles and reports, payment links, payout balance and top-ups, routing configuration delivered to processing over the bus. The sandbox hosts are being stood up next, so integration can start before the first acquirer signs. The first crypto rail is written and tested, and waits on a merchant account before it carries live traffic.

  3. Next

    Compliance and live rails

    PCI DSS assessment of the card perimeter, first acquiring contracts, and production traffic on payvan.net.

Building something that needs to take money?

We are looking for a small number of launch partners — teams who want to shape the API before it sets. Tell us what you are building and how you would want to charge for it.

[email protected] [email protected]