Reliability and testing

Test an integration

Test one boundary at a time, then connect them. Passing a simulated payment test does not establish physical charger interoperability.

flowchart diagram; its source follows
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.