What a payments provider port looks like, and which billing code belongs behind it #80

New Issue

2026-09-21T07:18:24Z

cgalo5758 commented

2026-09-21 07:18:24 +00:00

The question

Core billing code calls the Stripe client library directly. The fulfillment package imports it throughout despite its provider-neutral name, and the checkout handler, the catalog sync, the product readiness check and the member products page each call it from core as well, alongside the Stripe test helpers. The provider contract that other integrations are written against describes a lifecycle (create, set status, delete, read), which is not the shape of payments, so there is nothing for these calls to be written against. What operations does a payments port expose, and which of these behaviours moves behind it?

What depends on the answer

Whether a second payment provider is possible at all, whether the provider-specific action vocabulary that core carries for the outbox can move out of core, and whether the packages that read as provider-neutral become so or are renamed.

Options known so far

A payments port defined against the billing model, with the Stripe integration as its first implementation and fulfillment moving behind it.
Payments stays core-owned and single-provider by decision, and the packages that imply otherwise are renamed to say so.
Only fulfillment moves behind a port; the checkout hand-off stays provider-specific because its redirect is.

Decided when

The billing model states the port's operations and which package owns each side of it, and the integration contract says whether payments is a capability it describes or a separate seam.

Migrated from status/issues.md at b7a0e15

## The question Core billing code calls the Stripe client library directly. The fulfillment package imports it throughout despite its provider-neutral name, and the checkout handler, the catalog sync, the product readiness check and the member products page each call it from core as well, alongside the Stripe test helpers. The provider contract that other integrations are written against describes a lifecycle (create, set status, delete, read), which is not the shape of payments, so there is nothing for these calls to be written against. What operations does a payments port expose, and which of these behaviours moves behind it? ## What depends on the answer Whether a second payment provider is possible at all, whether the provider-specific action vocabulary that core carries for the outbox can move out of core, and whether the packages that read as provider-neutral become so or are renamed. ## Options known so far - A payments port defined against the billing model, with the Stripe integration as its first implementation and fulfillment moving behind it. - Payments stays core-owned and single-provider by decision, and the packages that imply otherwise are renamed to say so. - Only fulfillment moves behind a port; the checkout hand-off stays provider-specific because its redirect is. ## Decided when The billing model states the port's operations and which package owns each side of it, and the integration contract says whether payments is a capability it describes or a separate seam. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/billing area/integrations labels 2026-09-21 07:18:24 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#80