Skip to content

Payment Flow

Jump to bottom
Ewan Lyon edited this page Apr 18, 2022 · 3 revisions

Ticket ID

Example: T-5Y2K6BC6H

Generation

Ticket ID is generated via Nano ID.

Custom alphabet is used to remove similar symbols and only use capitals.

0123456789ABCDEFGHJKLMNPQRSTUVWXY.

Symbols removed are I, O and Z due to their similarity to 1, 0 and 2. Taken from Nintendo Store redeem codes.

ID length is 9 characters long which is an arbitrary value chosen as it is short to type but long enough to have a low chance of a collision as we are generating these blind. The Nano ID collision checker states that with the custom alphabet and character length that when generating 1000 IDs per second, it would take around 40 days to have a 1% collision chance. As we are a smaller scale event, even generating just 1 per second would take 110 years to have a 1% collision chance.

T- is then added as a prefix to the ID to provide more human readability that this is a ticket ID.

Usage

Ticket IDs are generated whenever a new ticket entry has been added. This is done via the resolveInput hook on the ticket schema. These are generated blind meaning that we do not check the database if it exists before adding it. The ticketID property is set to be unique so the database will error out if this occurs. Due to the low chance of this occuring I believe this is a non issue.

Payment methods

A UML sequence diagram is probably better but ¯\_(ツ)_/¯

Bank Transfer

  1. User sets number of tickets to purchase and presses the purchase button.
  2. New ticket entry added with the user ID and number of tickets to purchase and purchase method of "bank".
  3. Data returned from mutation query is the ticketID, total cost and the number of tickets.
  4. User is presented with the ticket ID and information on the BSB and Account number to send the total cost to as well with the reference ID. The reference ID being the ticket ID.
  5. Once a week the event coordinator will look through the bank transactions and search the reference IDs in the database and manually mark them as paid.
  6. The website will now say that the ticket has been paid and a barcode will be shown.

Stripe

  1. User presses the purchase button.
  2. User is redirected to /api/checkout_ticket?account=XXXXXXXX.
    • account contains the user Keystone ID.
  3. Stripe checkout session is created.
  4. New ticket entry added with the user ID (from account url query) and Stripe session ID populated.
  5. User is redirected to Stripe checkout URL.
  6. User can adjust the amount of tickets they want to purchase in Stripe checkout.

User purchases

  1. A webhook call is received from Stripe through /api/webhooks with the event checkout.session.completed.
  2. A request to Stripe is made to get the amount of tickets bought.
  3. The ticket entry is then modified to have the correct number of tickets and to set the ticket as paid.

User cancels

  1. The user is redirected back to the tickets page with the URL parameters cancelled=true and session_id={STRIPE_SESSION_ID}.
  2. The ticket page deletes the ticket if both URL parameters are found.
Clone this wiki locally