This module is optional
Modules 1–8 are the full-day workshop — TaskFlow is already complete without this. This is a self-paced bonus for after the day, showing how the same config-first model extends to accepting real payments. Nothing here is required to finish the core lab.
What you'll add
A TaskFlow Pro upgrade: a workspace clicks Upgrade, pays through Stripe's hosted checkout, and a subscription record lands with its status once payment confirms — no polling, no webhook code you have to write. You'll touch the same three roles Module 7 introduced (org admin, workspace admin, developer), extended to a connector that's two-legged and async instead of one-shot.
Why this isn't just another connector
Slack (Module 7) is one-shot: fire a request, done. A checkout is different — you start it now, and confirmation (did they actually pay?) arrives later, asynchronously, from Stripe's own infrastructure. Stripe, Paddle, and Dodo all share this two-legged shape: a direct checkout call that returns a redirect URL, and a signed webhook that lands the result on whatever entity you configure — plus one thing no other connector has, a per-workspace Product Catalog so a checkout call never needs to carry a raw provider price id.
1 · Org admin — enable Stripe
Same enable step as any other connector — Org Settings → Integrations → Stripe → Enable. You'll need a Stripe test-mode account; the secret key, webhook signing secret, and product catalog are entered by the workspace, not you, in step 3.
2 · Org admin — define the subscription entity and the webhook landing
Add a small entity to land the result on — the same create-entity flow you used for Project and Task in Module 2.
POST /api/create-subscription
{
"entityName": "subscription",
"entityIdFieldName": "id",
"UpdateParams": [
{ "name": "id", "colType": "string" },
{ "name": "status", "colType": "string" },
{ "name": "plan", "colType": "string" }
]
}Then, on Stripe's Customize → Webhook tab, configure where a confirmed subscription event lands: Target Entity = subscription, Operation = update, Target Row ID = {{ipaas_ref.entityRef}} (the optional entity_ref your app passes when checkout starts), and a Field Mapping for status.
3 · Workspace admin — credentials and product catalog
On the Connectors screen, under Credentials: paste the Stripe test secret key and a webhook signing secret, then Save (its own independent save action — it can never overwrite anything else on this screen). Under Product Catalog, map a label of your choosing to a real Stripe Price id you've created in test mode:
{ "pro_monthly": "price_..." }4 · Developer — call checkout from the client
The client sends only the label from step 3, plus a success/cancel URL — nothing identifying who's calling; that's stamped automatically from the signed-in user's own session. Everything workspace- or identity-specific — including resolving the label to the real Price id — happens server-side.
POST /app/{orgcode}/ipaas/stripe
{ "action_id": "checkout_price_recurring", "fields": { "product_name": "pro_monthly", "success_url": "...", "cancel_url": "..." } }result.checkout_url.checkout_url and pay with Stripe's test card 4242 4242 4242 4242.subscription row — check it: status is no longer pending.GET /app/{orgcode}/item/subscription/{id}
→ { "id": "...", "status": "active", "plan": "pro" }Try it
Run the four steps above with a real Stripe test-mode account. Then, in the Stripe dashboard, cancel the subscription and re-fetch the subscription row — its status updates again, asynchronously, with no code of yours in the path.
Going further: gating the upgrade isn't supported yet
If you wanted Pro offered only to workspaces not already on it, you'd normally gate the checkout call behind a condition in a Logic Block. That's not currently supported for payment connectors — Product Catalog label resolution only works on the direct route shown in step 4. Run any eligibility check in your own client/backend before calling checkout instead.