Payment Emulator exposes three independent gateway identities. Their names, checkout surfaces and visual assets belong to this project; third-party names appear only as compatibility targets that explain which documented API contract is being reproduced.
| Gateway | Compatibility target | Runtime status | Surface | Fidelity |
|---|---|---|---|---|
| Vector | Stripe | Implemented | Selected PaymentIntents and Refunds operations | Details |
| Harbor | PayPal | Implemented | Orders v2, Payments v2, OAuth and approval checkout | Details |
| Plaza | Mercado Pago | Implemented | Selected Orders operations | Details |
The project is independent and is not affiliated with, endorsed by, sponsored by or operated by Stripe, PayPal or Mercado Pago. Those names are used only to describe compatibility targets and source provenance.
“Implemented” is computed: a plugin must have routes and pass static conformance.
It cannot be typed into the gateways table. An operator may enable/disable a
gateway, mark planned/skeleton/deprecated and override accounting numbers, but
cannot edit routing, validation or toWire behaviour.
#Plugin responsibilities
| Concern | Plugin provides | Core provides |
|---|---|---|
| Identity | independent id/name plus descriptive compatibility metadata | registry and discovery |
| HTTP | compatibility routes and contract validation | wildcard entry and request ordering |
| Translation | compatibility request → canonical command; canonical view → wire | canonical operations/state |
| Credentials | compatible format, recognition and shaped refusal | digest lookup and tenant resolution |
| Idempotency | header name and required operations | fingerprint, lock, replay and conflict |
| Status/errors | total compatibility vocabulary | decision that a state/refusal exists |
| Accounting | fee/timing/currency declaration | balanced postings and settlement |
| Webhooks | topic, body, signature and verification | outbox, queue, retry and attempts |
| Checkout | independent URL template and payment-method catalogue | public checkout API and shared shell |
Plugins are plain objects with no injected dependencies. Backend behaviour lives
in apps/api/src/providers/<id>/; buyer-facing identity lives separately in
apps/checkout/providers/<id>/. The two applications share only API responses.
For the full addition workflow, see Adding a provider.