Purchase already includes workflow surfaces for customer portal access and purchase refunds.
Portal session
Use the portal workflow when you want the provider to handle self-service billing operations such as payment method updates or subscription management.
const portal =
yield *
sdk.portal.createSession({
customerId,
returnUrl: "https://app.example.com/account"
})Depending on the provider and flow, the runtime may also require an agreementId.
Why portal is modeled explicitly
Portal behavior is not identical across providers. Treating it as a workflow lets the SDK:
- validate local customer ownership first
- reject unsupported provider flows early
- keep provider-specific preconditions out of route code
Refunds
Purchase also exposes a provider-neutral refund workflow for one-time purchase agreements.
const receipt =
yield *
sdk.purchases.refund({
customerId,
agreementId,
reason: "support_resolution"
})Refund lifecycle
Why refunds belong in the runtime
Refunds are not only payment actions. They often affect invoice state, purchase grant validity, wallet balances, and entitlements.
That is exactly the kind of cross-cutting state change Purchase is meant to centralize.