Introduction

QairoPay is the only platform that issues white-label wallet passes for Apple Wallet and Google Wallet and settles the resulting payments in USDC on Aptos. This site is how you build with it.

What you can build

The QairoPay API exposes three product surfaces, each with its own resources but the same auth, idempotency, and webhook conventions:

• Pass — branded wallet passes with NFC, geofencing, dynamic fields, and a scanner SDK.
• Spend Card — virtual and physical debit cards issued via a sponsor bank, settled in USDC.
• Settlement — USDC on-ramp and off-ramp through Bridge, treasury accounting, and on-chain payouts on Aptos.

You can use any one of these independently or bundle them — most customers start with Pass and graduate to Spend Card and Settlement once the program scales.

How the platform is shaped

Three things to internalize before you write a line of code:

1. You are a tenant. Every API call is scoped to your tenant. Records cannot leak across tenants, ever. The platform is multi-tenant by design — see Tenancy model.
2. Sandbox is real. Every endpoint, every webhook, every error code in production is available in sandbox. Build against it with confidence — see Sandbox vs live.
3. Webhooks are first-class. Most state in the platform reaches you through webhooks (pass.installed, card.transaction.authorized, settlement.completed). Polling is supported but discouraged.

What’s here

Quickstart

Issue your first pass in under five minutes with a real cURL or TypeScript call.

Core concepts

Tenancy, idempotency, pagination, errors, rate limits, versioning. Read these first.

Guides

End-to-end walkthroughs for Pass, Spend Card, and USDC settlement programs.

API reference

Every endpoint, every parameter, every response. Generated from our OpenAPI 3.1 spec.

Help

Email developers@qairopay.com for technical questions. Production incidents go to the on-call rotation at oncall@qairopay.com. Subscribe to status for platform notifications.