01
Your app asks for access
A registered app starts an OAuth 2.0 authorization-code flow with PKCE. The request asks only for the scopes it needs.
Permission first. Provider execution stays with the provider.
A predictable connection flow for apps that need to use a customer’s existing payment account.
02
The user chooses an account
The user consents and connects their own Snippe or Abliner account. Provider credentials stay on the server side.
03
CamelPay routes a supported request
The app uses its scoped token. CamelPay validates the request and routes the supported operation to the connected provider.
04
Your app reconciles the result
Provider responses and signed callbacks help an app follow status. An acceptance response is not proof of final payment or settlement.
THE CONNECTION MODEL
App connects to a user’s provider through CamelPay.
Each hop is explicit. The application requests scoped access. CamelPay verifies the request and passes supported operations through. The provider decides what happens next.
- ✓OAuth scopes separate read access from write operations.
- ✓Idempotency keys help avoid duplicate creates on retry.
- ✓Callback signatures and event IDs support verification and deduplication.
What CamelPay does
Authorizes, validates, routes, and helps correlate supported provider requests and callbacks.
What the provider does
Controls account eligibility, methods, execution, fees, delivery, reversals, settlement, and final status.
A provider’s
202 Accepted response means the provider accepted the request. It does not guarantee that funds moved or settled. For uncertain outcomes, reconcile with the provider before creating a new operation.NEXT
See developer toolsBuild with the actual contract.
Start from the API schema and provider notes rather than assumptions.