Skip to main content
Experimental. 86d Payments does not exist as a live service, so this Module has nothing to connect to. It is documented because it is in the registry, not because you can use it. See maturity levels.
When 86d Payments arrives, a Managed Deployment will not hold provider credentials of its own. This Module is how a managed Store Runtime will ask the Control Plane to run a payment operation on its behalf, and how the durable outcome will come back. You will not install or configure it. Provisioning handles it. If you are taking payments today, you want Set up a payment provider instead. Source: modules/managed-payments · npm: @86d-store/managed-payments

​
Why it exists

Provider secrets never enter a Store Runtime. That constraint is what makes managed payments safe to operate: a compromised Store container has no credential that can move money, because it never had one. So the split is: This Module is the seam. It authenticates with the Store’s Workload credential, submits an operation, and applies the confirmed outcome to the local Payment record.

​
What it does

It requires @86d-store/payments and reads paymentStatus and paymentAmount from it. It registers one Store endpoint and one outcome consumer. Four operation kinds cross the boundary: authorize, capture, void, and refund. Three shopper-visible options are supported: card, apple_pay, and google_pay. Every operation runs in sandbox or live mode, explicitly, with no implicit default.

​
Store endpoint

​
POST /payments/managed/prepare

Prepares a managed payment operation for the current Checkout. It authenticates as the Store’s workload identity rather than as a Shopper, so a browser cannot call it into doing anything on its own.

​
Workload scopes

The token this Module exchanges for is scoped to five permissions and nothing else: The audience is https://86d.app/api/store-runtime. A token minted for anything else is rejected.

​
Outcomes arrive once

An outcome carries an event id, a version, and a payment sequence number. The consumer deduplicates on the event id and refuses to apply an outcome out of sequence, then acknowledges it. That is what stops a redelivered webhook from refunding a Shopper twice. Each outcome names its provider, its mode, its connectionId, and a state of confirmed or declined. There is no third state meaning probably.