Offer your merchants confidential stablecoin payments
One more payment option. Merchant revenue stays off the chain.
How a rival poaches your merchants
- block explorer
- → merchant 0412 deposit
- this month: 84,000 USDC
01 Merchant volumes are public.
- rival’s pipeline
- Merchant 0412: 84k/mo
- current gateway: you
02 A rival reads your book.
- sales email
- To: merchant 0412
- We’ll beat their rate.
03 They pitch your best merchants.
What changes in your checkout
Nothing is replaced. Curvy is one more option at checkout, next to what you already take.
Today
Your checkout
With Curvy
Your checkout
Your platform: create and confirm through the SDK
What a merchant address leaks
All of it is readable from one public address, by anyone, for as long as the chain exists.
- 01 Revenue Gross sales, updated every block.
- 02 Customers Customer count and repeat rate.
- 03 Pricing Discounts and negotiated rates.
- 04 Your book of business Rival gateways see who you serve.
How it works
- Payment request Created
- ref
- ref #3307
- amount
- 1,200.00 USDC
01
Create a request
Your server, one per order
- Payment request Paid
- ref
- ref #3307
- amount
- 1,200.00 USDC
- from
- customer wallet
02
Customer pays
From the wallet they have
- Payment request Shielded
- ref
- ref #3307
- amount
- 1,200.00 USDC
- from
- customer wallet
- to
- hidden
03
Shielded on arrival
Fresh address, every time
- Payment request Confirmed
- ref
- ref #3307
- amount
- 1,200.00 USDC
- from
- customer wallet
- to
- hidden
04
Order confirmed
Matched by reference
- Sits next to your checkout
- Server-side SDK
- AML via viewing key
- USDC + USDT on Arbitrum
Is it right for you?
Good fit if
- You process stablecoin payments for merchants
- Merchants ask why their payments are public
- You serve VPN, SaaS, B2B or privacy merchants
- You can add a method to your checkout
Not yet if
- Your merchants need chains other than Arbitrum
- You need fiat settlement from this option
- Your volume is mostly Bitcoin
- You need it live with no integration work
Which of your merchants want this
-
VPN and privacy
Their users expect privacy end to end.
-
SaaS
Enterprise discounts stay private.
-
B2B services
Client lists and rates stay private.
-
Donations
Donors stay unlisted.
Who sees what
The payer’s own transfer is always public.
| who | The payment | Which merchant | Merchant revenue |
|---|---|---|---|
| The public | Can see | Hidden | Hidden |
| The merchant | Can see | Can see | Can see |
| Merchant’s accountant | Can see | Only if you share your viewing key | Only if you share your viewing key |
What gateways ask us
-
Integration
One more method. Your checkout stays.
-
Many merchants
Talk to us about multi-merchant setups.
-
AML
Screening before shielding. Viewing keys after.
-
Custody
Non-custodial. Funds never sit with Curvy.
-
Customer experience
Pay from the wallet they have. No account.
-
Coverage
USDC and USDT on Arbitrum today.
Built to be checked
Private, not unaccountable. How the compliance model works
Questions
Can we offer it next to our existing checkout?
Yes. It’s one more payment method, not a replacement. Merchants who want it switch it on. The rest keep their current setup.
Does the customer need a Curvy account?
No. They pay from the wallet they already use. The private part happens on the receiving side.
How do merchants reconcile and run AML?
Through the viewing key: read-only access to every payment and reference. Sending addresses are screened with Global Ledger before funds are shielded.
Which stablecoins and networks?
USDC and USDT, settled on Arbitrum. Talk to us about other networks.
Your merchants’ revenue is nobody else’s business.
Tell us how you take payments today, and we’ll show you where Curvy fits.
Read the docs- Your payment flow, step by step
- What stays visible, and to whom
- How the SDK fits your stack
- Your compliance questions