Post-booking checkout

Post-booking checkout: buying add-ons on-platform

Turning an offline WhatsApp sale into an inline purchase, on the 2026 design system

Standfirst

Almosafer sold add-ons after booking through a flow that was not really a flow. Users saw an add-on, wanted it, tapped it, and got handed to a WhatsApp agent. I rebuilt the purchase as a proper inline checkout on the 2026 design system: a cart that holds more than one add-on, fast checkout on the card already on file, and one uncomfortable trade-off stated out loud instead of buried.

The problem

You could not buy an add-on online once you had booked. The moment someone wanted one, they were pushed into WhatsApp and the sale turned into a manual, offline process, off the platform and out of the flow.

The tap-through was healthy. People saw the add-ons and reached for them. Almost none of them ended up buying. The intent was already there. What lost it was the handoff.

They wanted it
Users tapped the add-ons regularly. The offer was landing.
They could not buy it
No online purchase existed. Every sale left the platform for WhatsApp.
So almost nobody did
Attachment stayed low. The handoff, not the offer, was losing the sale.

The opportunity

Keep the purchase on-platform and treat an add-on like any other booking.

Buy it where you see it, with no channel switch. Give it a real booking summary: price, terms, what is actually included. Give it a cart that holds several add-ons instead of a single-item hack. And make the benefits screen something the user reads before the add-on lands in the cart, not after.

The flow

Before
Add-on WhatsApp Offline sale
After
Add-on Details Cart Review Pay Confirmation Add-on owned

The decisions

Cart and payment stay split.
Merging them into one screen is tempting when the purchase is small. But add two or three add-ons, a wallet toggle, a loyalty choice and a VAT line, and that one screen becomes the long, cart-hiding screen it was supposed to avoid. I bought the step back with an express path instead of merging.

Fast checkout on the saved card.
The booking already holds a payment method. Checkout defaults to it, so the common case is a single confirm rather than typing a card in again.

One reward per transaction.
The user picks which loyalty programme earns, explicitly, rather than being served competing prompts and left to work out what happens.

Wallet spend earns nothing, and we say so up front.
Paying from the wallet earns no loyalty points. Rather than let people find that out afterwards, the flow says it on the screen where the choice is made, and shows both sides: pay by card and earn, or pay by wallet and don’t. The trade-off stops being a surprise and becomes a decision.

The flow

Full board also found here!