The Division Of Labour
Vivenu is the shop. It owns the ticket types, the prices, the stock, the payment and the ticket itself. GKL Platform owns everything Vivenu cannot know: whether a particular driver is allowed to buy a particular ticket, and which driver a ticket belongs to.The booking website never talks to Vivenu’s API. Every call goes through GKL API, which proxies to Vivenu. The only time the customer touches Vivenu directly is to pay, and to view a ticket barcode afterwards.
Where Customers Come From
Customers do not arrive at the booking website directly. They arrive at the apex domain,fat-kartingleague.com, which is the marketing site. It carries the list of events, and each one redirects through to our booking website at events.fat-kartingleague.com.
The dependency also runs the other way. The CloudFront distributions in front of both web apps use www.fat-kartingleague.com as their fallback origin, so a failure on our side sends visitors to the marketing site rather than an error page.
The Path
1
The site asks what this user can buy
The booking website requests the availability tree for an event and a user. GKL returns, for every driver that user owns, the ticket types that driver may buy, split into perfect and close matches. See Ticket Eligibility.
2
The customer chooses tickets for drivers
Selection happens in our UI, not Vivenu’s. Each line is a ticket type paired with a specific driver.
3
GKL creates the checkout in Vivenu
GKL calls Vivenu to create a transaction checkout, carrying the chosen items, any vouchers and coupons, a sales channel of
sch-web, and the metadata described below.4
GKL pre-fills the customer details
A second call sends the user’s name and email to the checkout, so the customer does not retype what we already hold.
5
The customer pays on Vivenu
GKL returns a checkout URL into the Vivenu shop with
step=2&noSteps=true, which drops the customer straight onto payment rather than the start of Vivenu’s own flow.6
Vivenu tells us what happened
Checkout, transaction and ticket webhooks arrive back at GKL, HMAC signed. Each is mirrored into our own collections.
The Driver Linkage
This is the part nobody would guess, and it is what makes the whole model work. When GKL creates the checkout, it attaches metadata that Vivenu stores and hands back untouched:
So the driver is decided before payment, travels through Vivenu as opaque metadata, and comes back on the ticket webhook. When that webhook arrives, GKL reads
gklUserId and gklDriverId out of the ticket’s meta and stores the ticket already attached to the right driver.
That fallback order is also why a ticket created outside our checkout flow, directly in Vivenu, arrives with no driver attached and has to be assigned by hand.
What Else The Checkout Endpoint Handles
Aborting. A customer can abandon a checkout. GKL fetches it from Vivenu, confirms thegklUserId in its metadata matches the caller, and only aborts if the status is still NEW. Anything further along is refused.
Discounts. A code is validated against Vivenu for the event’s seller, and comes back classified as a coupon or a voucher, with a state. The distinction matters because they behave differently at checkout.
Free tickets. Operators issue these through the dashboard, which asks GKL to create them in Vivenu directly rather than going through a checkout.