The problem ApePay solves

ApePay

ApePay is a privacy-preserving crypto payment gateway for EVM (Ethereum) networks. It allows merchants to accept crypto payments (ETH and ERC-20 tokens) through a standard RESTful API while protecting customer and merchant privacy on-chain using a Zero-Knowledge (ZK) commitment protocol — zkBob.

In simple terms: ApePay is Razorpay for EVM networks, with privacy-preserving transactions that hide the direct on-chain link between the customer and merchant.

---

Where Can People Use ApePay?

1. E-Commerce & Digital Stores
2. SaaS & Digital Subscriptions
3. DAO, Freelance & Web3 Invoicing
4. Privacy-Sensitive Transactions

---

Key Problems ApePay Solves

1. Complex Blockchain API Integrations

Problem:
Integrating blockchain payments directly requires merchants to handle wallets, transactions, blockchain RPCs, confirmations, and payment tracking.

ApePay Solution:
Provides a Stripe/Razorpay-like REST API for creating and managing crypto payments.

• POST /v1/payments
• Scoped API keys using x-api-key
• Idempotency support using Idempotency-Key
• Simplified payment lifecycle for merchants

---

2. Building Custom Web3 Payment UIs

Problem:
Merchants would otherwise need to build their own Web3 payment interface, wallet connection flow, transaction submission logic, and payment status tracking.

ApePay Solution:
Provides a turnkey, responsive Hosted Checkout UI.

Checkout route:

/p/[paymentId]

Challenges I ran into

ApePay Architecture Decisions

1. Protocol Choice: ZK Proofs vs. Railgun vs. zkBob

I chose zkBob because it is purpose-built for lightweight token transfer privacy and pooled checkouts, whereas Railgun is designed for complex multi-token DeFi routing and custom ZK circuits carry extreme operational overhead.

2. zkBob Verification Problem & Intent Architecture

The Problem: On traditional EVM chains, payment gateways check:

from (customer) == to (merchant)
amount == X

Privacy protocols break direct from → to linkability because funds flow through a shared liquidity pool (PoolVault).

ApePay’s Solution

Payment Intent & Commitment Note (POST /v1/payments)

The backend creates a unique payment intent with a cryptographic commitment hash:

commitment = SHA256(paymentId : amount : currency)

Deposit with Commitment (PoolVault.deposit(bytes32 paymentId))

The customer deposits funds into the shared PoolVault contract along with the paymentId commitment in the calldata.

Event Indexing

The contract emits:

Deposited(paymentId, sender, amount)

The ApePay indexer matches the paymentId to mark the order as paid without publicly revealing the merchant's payout wallet address.

Decoupled Operator Payout (PoolVault.withdraw(...))

The operator batch-withdraws funds from the vault to the merchant's address, completely severing on-chain linkability between the customer wallet and merchant wallet.

3. Who Pays Gas?

Customer Pays Gas.

4. MetaMask vs ApePay Account

Does the customer have to create an ApePay account?

No.

The customer should ideally be able to:

Open checkout
      ↓
Connect MetaMask / wallet
      ↓
Approve payment
      ↓
Pay
      ↓
Done

Rather than:

Create ApePay account
↓
Create password
↓
Verify email
↓
Connect wallet
↓
Pay

That would destroy the simplicity expected from a payment gateway.

5. Merchant Embedding Model (Stripe / Razorpay Model)

Merchant Storefront
       │
       │ 1. POST /v1/payments (x-api-key)
       ▼
ApePay Backend API
       │
       │ 2. Returns paymentId & checkoutUrl
       ▼
Hosted Checkout Page (/p/:paymentId)
       │
       │ 3. Customer connects wallet & deposits into PoolVault
       ▼
ApePay Indexer & Webhook Engine
       │
       │ 4. HMAC SHA-256 Webhook (payment.paid)
       ▼
Merchant Order Fulfillment