Payment Flow

BizTech uses Stripe Checkout Sessions for all paid transactions — event registration fees and membership dues. The backend creates a session, the frontend redirects to Stripe's hosted checkout page, and a webhook confirms the payment.

Architecture

Frontend                      Backend (/payments)               Stripe
───────                      ──────────────────               ──────
POST /payments ───────────►  payment() handler
  { paymentType, email,       │
    eventID, year,            │ stripe.checkout.sessions.create()
    success_url, cancel_url } │────────────────────────────────► Session
                              │◄──────────────────────────────── { url }
                              │
                              │ Save checkoutLink on registration
◄─────────────────────────────┘ Return session.url

window.open(url, "_self") ──────────────────────────────────► Stripe Checkout

                              webhook() handler ◄─────────── checkout.session.completed
                              │ Verify signature
                              │ Read metadata.paymentType
                              │ Update DynamoDB state

Payment Types

The paymentType field in the request body determines the post-payment behavior:

Backend Endpoints

All handlers in services/payments/handler.js:

Session Creation payment()

File: services/payments/handler.js (line ~362)

Pricing logic

• Event payments: Fetches the event from biztechEvents and the user from biztechUsers. Uses pricing.members or pricing.nonMembers based on user.isMember. Multiplied by 100 for cents.
• Membership payments: Fixed MEMBERSHIP_PRICE = 1500 cents ($15.00 CAD). UBC students receive a $3 discount (unit_amount = 1200). Defined in services/payments/constants.js.

Session parameters

stripe.checkout.sessions.create({
  payment_method_types: ["card"],
  line_items: [{ price_data: { currency: "CAD", unit_amount, product_data }, quantity: 1 }],
  mode: "payment",
  metadata: { paymentType, email, fname, eventID, year, ... },
  success_url,
  cancel_url,
  expires_at: Math.floor(Date.now() / 1000) + 1800, // 30 minutes
  allow_promotion_codes: true,
});

All user form data is stored in the session metadata so the webhook can process it without a second database lookup.

For event payments, the returned session.url is also saved as checkoutLink on the registration record via updateHelper(). This allows re-registration to reuse the existing session URL.

Webhook webhook()

File: services/payments/handler.js (line ~36)

1. Verifies the Stripe signature using endpointSecret
2. Handles only checkout.session.completed events
3. Reads metadata.paymentType and dispatches to the matching helper:

Frontend Integration

Registration Strategy Pattern

The frontend uses an abstract RegistrationStrategy class to manage registration and payment state.

File: src/lib/registrationStrategy/registrationStrategy.ts

abstract class RegistrationStrategy {
  abstract needsPayment(): boolean
  abstract regForPaid(): Promise<{ paymentUrl?: string }>
  abstract regForPaidApp(): Promise<{ paymentUrl?: string }>
  abstract confirmAndPay(): Promise<{ paymentUrl?: string }>
  // ...
}

Concrete implementation: RegistrationStateOld in src/lib/registrationStrategy/registrationStateOld.ts

Checkout redirect

All three payment methods POST to /payments and redirect with:

const response = await fetchBackend('/payments', 'POST', paymentBody)
window.open(response, '_self') // redirects to Stripe hosted page

The success_url is constructed as CLIENT_URL/event/{eventId}/{year}/register/success.

Re-registration shortcut

In services/registrations/handler.js (line ~366): if a user tries to register but already has an incomplete registration, the backend returns { url: existingReg.checkoutLink } — the previously-saved Stripe session URL. The frontend strategy checks for res.url and returns it directly as paymentUrl before calling /payments.

Environment Variables

Defined in services/payments/serverless.yml:

Stripe is initialized at the top of handler.js:

const stripe = require('stripe')(
  process.env.ENVIRONMENT === 'PROD'
    ? process.env.STRIPE_PROD_KEY
    : process.env.STRIPE_DEV_KEY,
)

DynamoDB Tables

Key Files

Related Pages

• Registration — registration state machine that payment completes
• Membership Flow — full membership path including admin bypasses
• User, Member & Profile Relationships — the three records created by membership payment
• Authentication — Cognito auth context for membership signup
• Event Lifecycle — where payment fits in the broader event flow