Start Here
Understanding the interplay between backend APIs and client-side SDKs
How Mona Works
Mona’s architecture is built on Strong Customer Authentication (SCA) using cryptographic signatures from on-device credentials. Every sensitive operation—whether consenting to future collections or making payments—is cryptographically signed using passkeys or private keys stored securely on the user’s device.
This cryptographic foundation provides unparalleled security, but the complexity is completely abstracted away by our SDKs. You get enterprise-grade authentication without any of the implementation complexity.
Our architecture follows a secure two-step pattern that separates backend operations from client-side implementation. This ensures your sensitive API keys never leave your server while providing seamless user experiences in your apps and websites.
Strong Customer Authentication (SCA)
At the heart of every Mona interaction is Strong Customer Authentication. This isn’t just about passwords or SMS codes—it’s about cryptographic proof that the user is who they claim to be and that they genuinely intend to perform the action.
🔐 Cryptographic Signatures
- Every payment and collection consent is cryptographically signed
- Uses on-device credentials like passkeys, biometrics, or secure private keys
- Cannot be replicated, intercepted, or faked by malicious actors
- Provides non-repudiation: mathematical proof of user intent
🛡️ What Gets Authenticated
- Payment Authorization: Every transaction requires cryptographic consent
- Collection Consent: Recurring payment permissions are cryptographically signed
- Account Linking: Bank account connections use secure authentication
- Sensitive Updates: Any account changes require re-authentication
✨ SDK Abstraction
The SDKs handle all the cryptographic complexity:
- Automatic Key Management: Generate, store, and manage cryptographic keys
- Secure Signing: Handle all cryptographic operations transparently
- Cross-Platform: Same security level across Web, iOS, Android, Flutter
- Fallback Handling: Graceful degradation when hardware security isn’t available
- Compliance: Built-in PSD2, PCI DSS, and regulatory compliance
You get bank-level security without writing a single line of cryptographic code.
The Two-Key System
🔒 Private API Key (Backend Only)
- Used for all server-side API calls
- Never exposed to client applications
- Authenticates requests to create transactions, collections, etc.
- Format:
x-api-key: your_private_key
🌐 Public Key (Client-Side)
- Used to initialize SDKs in your apps/websites
- Safe to include in client-side code
- Loads your merchant branding and configuration
- Format:
mona_pub_xxxxx
The Integration Flow
Every Mona integration follows this secure pattern:
Step 1: Backend Creates Resource
Your server uses the private API key to create a resource and get an ID:
Examples:
- Checkout: Create transaction → Get
transactionId
- Collections: Create collection → Get
collectionId
- Identification: Create verification → Get
verificationId
Step 2: Client Uses Resource
Your app/website uses the public key + resource ID to initialize the SDK:
Practical Examples
Checkout Flow
Collections Flow
Getting Your Keys
During onboarding, the Mona team will provide:
-
Private API Key: For server-side API calls
- Sandbox:
mona_sk_sandbox_xxxxx
- Production:
mona_sk_prod_xxxxx
- Sandbox:
-
Public Key: For client-side SDK initialization
- Sandbox:
mona_pub_sandbox_xxxxx
- Production:
mona_pub_prod_xxxxx
- Sandbox:
Next Steps
- Choose Your Component: Checkout or Collections
- Implement Backend: Use the API reference to create resources
- Integrate SDK: Follow platform-specific guides for your app
- Test End-to-End: Verify the full flow in sandbox environment