Buyer TEE Verification

Buyer TEE Verification is how Peer verifies a buyer's payment. The buyer's client verifies the Attestation Service enclave, encrypts the buyer's payment-platform session to it, and the enclave fetches and checks the payment itself. The result is a standard PaymentAttestation; the contracts treat it like any other attestation.

Supported platforms

Platform	Buyer flows
Venmo	transfer_venmo
Cash App	transfer_cashapp
PayPal	Personal (transfer_paypal), Business (transfer_business_paypal)
X Money	transfer_xmoney
Wise	transfer_wise
Revolut	transfer_revolut
Monzo	transfer_monzo
Chime	transfer_chime
Zelle	Chase, Bank of America, Citi and Capital One
Alipay	transfer_alipay
UPI	Amazon Pay (transfer_upi_amazonpay)
Monobank	transfer_monobank

GET /buyer/supported on the Attestation Service lists the current set. Each platform's request format and response parsing belong to the service; don't copy provider headers or fields into an integration.

Flow

1. The buyer signals an intent and pays the seller on the selected platform.
2. The client calls GET /attestation?nonce=... and verifies the AWS Nitro attestation document before handling any session material.
3. The client encrypts the platform session as a compact JWE to the enclave's upload key. The ciphertext is bound to that key, the platform and the action type.
4. The client sends the ciphertext, public params, chainId and the intent to POST /buyer/verify/:platform/:actionType.
5. Inside the enclave, the service decrypts the session in memory, calls the platform over HTTPS with certificate and hostname checks, and normalizes the payment.
6. The service checks the payment against the intent (method, currency, payee, time, intent hash, conversion rate and amount) and signs the PaymentAttestation.
7. The client submits it to OrchestratorV4.fulfillIntent, where UnifiedPaymentVerifierV4 checks it and the escrow releases funds.

@zkp2p/zkp2p-attestation provides verifyBuyerTeePayment() for steps 2–4.

Security properties

• Clients verify the enclave before encrypting anything; the service rejects plaintext session material.
• Encrypted sessions only work for the enclave key, platform and action they were encrypted for.
• The enclave signs only after the payment matches the intent.
• Treat the encrypted session as sensitive. It stays usable for as long as the underlying platform session is valid, so if it leaks, end that platform session.

In the app

For the buyer this is a normal verification step: pay the seller, return to Peer, sign in to the payment platform or select the payment when asked, and wait for the order to complete. On the web, the PeerAuth extension captures the session; the mobile app does this in-app.

X Money

X Money payments must be outgoing, person-to-person transfers in USD. Settled payments are accepted. Payments marked "Awaiting access to Money" or "Awaiting acceptance" can also be verified, and your USDC may be held for 14 days while the recipient sets up X Money or accepts the payment. Other pending, cancelled, or expired payments are rejected. Peer web needs PeerAuth extension version 0.7.6 or newer. Authentication opens the X Money balance page; open the payment to capture it, then return to Peer and select it.