Integrating a payment processor
Your application can integrate a payment processor without an Ivora adapter. Keep processor credentials, merchant records, checkout UI and business profiles in your application and its database. Use the shared API for charger management, trusted usage, cost calculation and settlement references.
| Choice | Integration owner | Ivora contract |
|---|---|---|
| Application-managed payment | Your backend owns checkout, authorization, capture, refunds and recovery | External charging sessions |
| Managed payment adapter | A separately deployed adapter executes the processor lifecycle | Managed payments; only registered services are available |
Self-service registration of managed adapters remains planned. A processor name in an external session is descriptive metadata; it does not install an adapter or cause Ivora to call that processor.
Charging and payment sequence
Choose a payment model supported by your processor. For metered charging, your backend normally establishes funding before start and settles the final amount after trusted usage is available. Fixed-price, prepaid or included charging policies also belong to your application.
Diagram source
flowchart TD
UI[Application checkout] --> Backend[Application backend]
Backend --> Funding[Establish funding with selected payment service]
Funding --> Verified{Funding confirmed?}
Verified -->|No| Wait[Keep charging unstarted]
Verified -->|Yes| Charge[Create and start API charging session]
Charge --> Usage[Observe charging and confirm completed usage]
Usage --> Bill[Finalize immutable charging bill]
Bill --> Settle[Application settles or releases payment]
Settle --> Report[Optionally report settlement outcome to API]The API enforces tenant/resource access and correlates the bill with a charging transaction. It cannot verify your external funding assertion. Your backend verifies payment outcomes using the processor's documented server interfaces; browser redirects and client-supplied amounts are not proof of payment.
Recovery responsibilities
Store stable application, payment and operation references before dispatch. Reuse the same idempotency key for the same request after a timeout. Read the existing operation/payment before issuing a new financial effect. Handle duplicate and out-of-order notifications according to the processor's contract.
Authorization expiry, insufficient funding, declines, failed starts and late metering need application policy. An API bill establishes cost; it does not establish that the cost was collected. Optional settlement reports remain application assertions, and the API never executes a transfer from a report.
Business names, support contacts, billing addresses, booking details and free-charging eligibility are application records. Send opaque references and charging resource identifiers to Ivora, without customer profiles or passwords.