How It Works
Rezva is a shared payment resolution layer. Customers pay through a compatible wallet. Merchants register identifiers once. Wallet apps look up destinations without rebuilding their payment rails.
What Rezva does
Rezva sits between identifiers people already know and the crypto destinations payments should reach. It does not hold funds, run card rails, or replace apps like bKash or PayPal. Compatible wallets ask Rezva where an identifier points, then settle the payment themselves.
- Not a wallet and not a custodian
- Not a payment processor or settlement network
- A shared lookup layer any approved wallet can call
- One registration can serve many compatible wallets
- Supports phones, emails, regional QR, custom IDs, and provider namespaces
At a glance
MerchantRegisters and manages
→@merchantIdentifier
→RezvaShared lookup layer
→Payment destinationWhere funds are received
Customer walletWants to pay @merchant
Lookup
Rezva returns the linked destination
For users
If you want to pay someone, you stay in a compatible wallet. Rezva helps that wallet find where to send the payment.
- 1
Scan or enter an identifier
Use a phone number, Bangla QR / EMV payload, email, merchant ID, custom handle, or a provider name such as alice.rabby inside your wallet’s send flow.
- 2
Your wallet resolves it
The wallet calls Rezva with the typed value. You do not need the merchant’s own app, and you do not paste a raw chain address unless you choose to.
- 3
Review the options
Your wallet shows payable networks, assets, and destinations it supports. It can also surface safety signals such as pending activation or a recently changed destination.
- 4
Confirm and pay
Pick an option and confirm in your wallet. Rezva does not move the money. Your wallet signs and broadcasts the transaction.
For merchants
A merchant, creator, freelancer, or any controller registers identifiers people already recognize and links them to where crypto payments should arrive.
- 1
Apply on the business track
Sign in to the Rezva dashboard, connect a controller wallet, and complete business approval before registering production identifiers.
- 2
Register an identifier
Add a phone, email, Bangla QR string, merchant ID, PayPal handle, custom identifier, or another active type. Full regional QR text can be registered and matched exactly.
- 3
Link payment destinations
Choose the chain, asset, and receiving address for that identifier. Destinations can be updated later with the same controller authorization.
- 4
Get paid from compatible wallets
Register once. Customers can pay from different wallet apps as long as those wallets support Rezva resolution for that type.
New identifiers may stay pending for a short safety period before they become payable. Destination changes can enter update_pending so wallets can warn users when a mapping was recently updated.
For wallets
Wallet providers add Rezva beside the payment flow they already have. They keep signing, custody model, and settlement. Rezva only answers where an identifier points.
Resolver only
The smallest integration. Resolve identifiers and show destinations inside the wallet’s existing send UI.
- POST /v1/resolve with an approved provider key or Free API key
- Accept typed values including full Bangla / EMV QR payloads
- Resolve provider names such as alice.rabby
- Show status, payment readiness, and safety timestamps
- Pay with the wallet’s existing transaction flow
Resolver + merchant setup
Everything in resolver only, plus flows for controllers to register and manage identifiers from the wallet.
- Check identifier availability
- Register identifiers and payment destinations
- Update or remove mappings with controller authorization
- Offer merchant setup without sending users to a separate app
Provider namespaces
Approved wallet providers can claim a namespace (for example .rabby) and register payable names under it.
- Apply for a namespace in the provider dashboard
- Register names like shop.rabby with a destination wallet
- Resolve them as type provider_name through the same API
- Keep namespace policy and reserved labels under provider control
Production resolver access is permissioned. Providers apply, get reviewed, and receive credentials. Free API keys are for prototypes and the shared Test Merchant only.
Identifiers
Identifier types are lookup namespaces. They help wallets find a destination. They do not replace the original payment network behind a phone number, QR scheme, or app username.
- Phone & emailNormalized contact identifiers for high-sensitivity mappings.
- Bangla QR / EMVFull regional QR payloads (up to 700 characters) matched as the exact registered string.
- Merchant ID, PayPal, bKash, customFamiliar merchant handles and operator-controlled custom values where enabled.
- Provider namesNamespace names such as alice.rabby resolved as provider_name after the provider registers them.
- Protocol native namesProtected or dictionary-reviewed names when the registry policy allows them.
Wallets should discover active types from GET /v1/identifier-types instead of hard-coding the set. Eligibility for registration and resolution can change independently.