A port defining createCheckout, listSettledPayments, getPayment, listEnabledOrgIds, isConfigured and verifyWebhook. Payments are single-provider per account (one merchant account) rather than a fallback chain: the first active binding wins, defaulting to Stripe. The platform's own subscription billing is deliberately a separate flow behind its own named boundary.
Also called: payment provider · second processor · PaymentsPort
- 1paymentsFor(orgId) reads the account's payments binding and returns the adapter, defaulting to Stripe.
- 2Routes call the port rather than the vendor SDK.
- 3allPaymentAdapters() lets the reconcile sweep cover every provider.
- 4The platform-level subscription Stripe is exported under its own boundary name so the two are never confused.
The registry states the modelling decision: 'Payments is single-provider per org (one merchant account), not a fallback chain: the first active binding wins, defaulting to Stripe. A second processor becomes selectable per tenant via a registry row.' The platform boundary exists because 'This is the OTHER Stripe: subscriptions charged on the PLATFORM's account, entirely separate from the org-merchant PaymentsPort', and the separation is made greppable on purpose.
- Payment vendor choice was hard-coded.
- The platform's own billing and the builder's customer payments were easy to conflate.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →