Recipes
These recipes follow a purchase from immutable offer registration through payment and the product-specific operation that follows settlement.
| Product shape | Complete flow |
|---|---|
| Ebook | Checkout to protected download |
| Simple SaaS | Subscription purchase and renewal |
| Tiered SaaS | Basic-to-Pro next-period upgrade |
| Usage-based API | Enrollment, usage, invoice, and collection |
| Team product | Seat purchase and assignment |
| Subscription desktop app | Subscription-backed license |
| Perpetual desktop app | Perpetual license lifecycle |
| Credit pack | Reserve, consume, or release credits |
| Desktop bundle | Independent access and credit lifetimes |
| External course | Durable external fulfillment |
Before using a recipe
Section titled “Before using a recipe”Every imported SAPA operation returns an Effect requiring the request-scoped
Sapa service. Provide your composed runtime Layer at the HTTP handler, job, or
other application boundary. The snippets call the package directly; SAPA 0.1.x
does not provide a hosted API or a Promise client.
The examples use midtrans and IDR. They deliberately leave these
installation-owned values as parameters:
sapaRuntimeLayer: storage, provider, clock, crypto, and installed capability Layers;rawProviderPayload: the untouched, size-bounded webhook body authenticated by the provider adapter;- the authenticated customer or merchant subject supplied by your host application;
- fulfillment and email workers supplied by the deployment runtime.
Never treat checkout creation or a browser return URL as payment. Only
processPaymentNotification accepts authenticated settlement and creates paid
benefits.