ProjectFlowPro
Menu

Case study · Cloud infrastructure

Payments to provisioned HTTPS sites

Implemented · tested (static) · deployment documented

Automation that turns a card payment into a live, secure website. It records the purchase, sends an activation link, creates the customer's site and, if they bring their own domain, walks them through DNS setup and issues the certificate automatically, checking that everything works before declaring the site live.

AWS · one CDK app · 2 stacks · 11 constructs

Clients

  • Visitorseach tenant site, on its own domain
  • BuyersTemplate Hub checkout and activation

Edge and hosting

  • CloudFrontone multi-tenant distribution
  • Edge functionroutes each host to its tenant
  • S3one private bucket, a prefix per site
  • Certificatesone per custom domain

API

  • API Gatewaythe marketplace API
  • CheckoutLambda · Stripe session
  • Stripe webhookLambda · signature verified, idempotent
  • ActivationLambda · one transaction
  • FormsLambda · atomic rate limit

Data and messaging

  • DynamoDBorders, entitlements, tenants, routing
  • SSMSecureStrings and price IDs per environment
  • Queue → SESform delivery, with a dead-letter queue

Workflows

  • Step Functionscustom domains, up to 48 hours
  • Ownership probefive clean rounds across resolvers
Verified Architecture Diagram From the infrastructure's CDK app: 28 Lambda handlers, tested by 29 Jest suites (490 passing tests).

Purpose

Automation that turns a card payment into a live, secure website.

The problem

Each payment must produce exactly one order and one site, and a customer’s own domain must be proven and secured before the site is declared live.

What it contributes

Provisioning and hosting, in the WebWorks line: purchase, activation, site creation, domain setup and certificate issue, checked before the site goes live.

Principal capabilities

  • Infrastructure

    A single AWS CDK application in TypeScript, deployed per environment, with a local emulation target. Sites are served from one storage bucket through a multi-tenant CloudFront distribution, with an edge function routing each host to its tenant.

  • Backend

    Checkout and payment-webhook functions sit behind API Gateway, read secrets from a parameter store, verify webhook signatures and write with DynamoDB conditions, so each payment produces exactly one order and entitlement. Activation is one transaction: an unused hashed token, a remaining activation and a unique site-name claim.

  • Integrations

    Custom domains run through a 48-hour Step Functions workflow: provider-managed DNS with automated certificate validation, or customer-managed DNS with emailed instructions and an ownership probe that needs five consecutive clean rounds across several resolvers. The workflow then creates or reuses the tenant idempotently, applies the certificate, and verifies the site serves before succeeding.

Built with

  • AWS CDK
  • TypeScript
  • Lambda
  • API Gateway
  • DynamoDB
  • CloudFront
  • Step Functions
  • SES
  • SSM
  • Stripe
TypeScriptwebworks-marketplace-infra/lib/functions/form-submission/handler.ts
const window = Math.floor(nowMs / 1000 / RATE_WINDOW_SEC);
await ddb.send(
  new UpdateCommand({
    TableName: tableName,
    Key: { PK: `FORMRATE#${slug}#${ipHash}`, SK: `WINDOW#${window}` },
    UpdateExpression: "ADD #c :one SET expiresAt = :exp",
    ConditionExpression: "attribute_not_exists(#c) OR #c < :limit",
    ExpressionAttributeNames: { "#c": "count" },
    ExpressionAttributeValues: {
      ":one": 1,
      ":limit": limit,
      ":exp": (window + 1) * RATE_WINDOW_SEC + 3600,
    },
  })
);
Serverless · an atomic rate limit in DynamoDB. Per visitor and tenant, 5 per 10 minutes by default; only a hash of the IP is stored, and the row expires by TTL. Verbatim excerpt from the repository.

Implementation evidence

  • 2 CDK stacks, 11 constructs and 28 Lambda handlers.
  • 29 Jest suites, 490 passing tests, including synth-level assertions.
  • Deployment documented.

Back to WebWorks website ecosystem

Visual evidence

  1. 01Pay

    Checkout creates a Stripe session from the price IDs in SSM.

  2. 02Record

    The signed webhook writes order, entitlement and token in one transaction.

  3. 03Activate

    An unused hashed token, a remaining activation and a unique site name, claimed together.

  4. 04Connect

    The domain workflow proves the domain and issues its certificate.

  5. 05Serve

    The tenant goes live on CloudFront once the site is verified serving.

Verified Architecture Diagram Each step is one of the infrastructure's functions or workflows; payments and activations are written with DynamoDB conditions, so a retried call never makes a second order or site.
Step Functions · custom domain · up to 48 hours
  1. 01Choose DNS

    Provider-managed DNS, or the customer keeps their own.

  2. 02Prove ownership

    Automated certificate validation, or emailed instructions and a probe that needs five consecutive clean rounds across several resolvers.

  3. 03Create the tenant

    Created or reused idempotently on the multi-tenant distribution.

  4. 04Apply the certificate

    Issued for the domain and attached to the tenant.

  5. 05Verify it serves

    The workflow succeeds only once the site answers on its domain.

Verified Architecture Diagram The steps of the infrastructure's domain workflow.

Part of

WebWorks

Turn proven website designs into knowledge, create new sites from it, then sell and launch them automatically.

Other case studies in this project

  • Backend / Python

    WebWorks Generator (WWG)

    Turns an existing web page into a reusable React/Next.js page, separating components, content, theme and local assets. It then verifies the result against the source one dimension at a time, so approval is attached to the exact generated artifact rather than assumed from a successful build.

    Implemented · 9 production builds recorded, 5 operator-approved · 143 Python test files

  • Frontend

    Review console

    A local review harness for checking generated pages stage by stage. It renders the same component tree with successive layers enabled so an operator can tell whether a defect came from components, runtime behaviour, content, theme or the final composition before approving a dimension.

    Implemented · local · per-page rendering documented

  • Data

    Knowledge Base (KB)

    The design knowledge of the WebWorks line. It learns from the generator's processed pages how website pages are designed (layouts, sections, blocks, style systems, and card and background treatments) and supplies that knowledge to WebsiteCreator.

    Implemented · supplies WebsiteCreator

  • Design method

    WebsiteCreator

    Creates new websites. It takes the Knowledge Base’s understanding of page design, writes a design guide for each site on a set structure of rules, in accordance with the Knowledge Base, and builds the pages from it.

    Implemented · builds new sites from Knowledge Base design guides

  • Frontend

    Checkout-to-activation storefront

    An online store where a small business chooses a website, pays by card and launches it on its own address without contacting anyone. After payment it receives an activation link, picks a name or connects its own domain, and the site is set up automatically.

    Implemented · tested