Test an integration
Test one boundary at a time, then connect them. Passing a simulated payment test does not establish physical charger interoperability.
Diagram source
flowchart TD
Contract[Schema and tenant authorization tests] --> Fault[Duplicate and failure-injection tests]
Fault --> Simulation[Isolated simulated usage]
Simulation --> Provider[Processor sandbox acceptance]
Provider --> Hardware[Authorized physical charging acceptance]
Hardware --> Reconcile[Recovery and settlement reconciliation]Payment scenarios
Exercise duplicate and concurrent requests, conflicting keys, dropped replies, process death after a provider effect, expired authorization, declined cards, zero usage, usage above the hold, capture/refund failures and late events. Verify that tenant A cannot access tenant B's bill, session or merchant mapping.
For an application-managed processor, add forged and duplicate webhook events, out-of-order delivery, merchant mismatch, revoked credentials and independent application/processor restarts. Ivora tests the external session/report contract; processor-specific verification and webhook handling are your backend's responsibility.
Existing verification
September 29 live payments, in source and not yet deployed: 407 offline API and
provider tests against a fake Stripe transport that returns Stripe's object shapes
cover direct charges on the pinned payment account,
the live-mode checks on every Stripe object that carries one, onboarding with and
without review, staff pins, the new error codes, capture within the hold and the
billing:refund scope. No live Stripe call and no physical charging were part of
those tests; live acceptance follows Ivora's own staff session before drivers pay.
September 28 charger displays, in source and not yet
deployed: offline tests prove the built-in RCD and Sinexcel adapters send the
same bytes as the legacy payment service for representative tariffs. Tests
against a mocked core cover desired state, pricing from tariff_id, reboot
re-push, backoff and its reset on new desired state, an unreachable core,
clearing, tenant isolation and administrator roles. No simulator or physical charger
acceptance has run.
The recorded September 22 preproduction migration passed 86 offline API/payment tests, including concurrency, malformed receipts, recovery and subprocess crash cases. Frontend/browser checks covered direct API routing, private sessions, retry identity, summary units, compatibility aliases and Swagger. These are dated results; rerun the relevant checks for your release.
Earlier managed-adapter acceptance exercised Stripe test-mode authorization, capture, refund, unused/zero release and decline with simulated usage. Physical charging-to-settlement acceptance, 3DS/expiry coverage and automatic reconciliation remain incomplete. Existing driver writes were mocked/intercepted in the migration browser suite.
Developer workflow
Send explicit requests with a read-only key first (the API reference has a sample for each operation). Use tenant simulated bills or the workspace sandbox before hardware. Keep test users, keys, records and endpoints separate from production. Never use real card data in an agent prompt or test fixture.
Repository maintainers run the isolated API gate with
python -m staging.verify_payments in the configured test environment. The
documentation site itself can be built and browser-tested without API credentials
or running services.