Payment Link

Map 2

Send a link, take the payment, show the status

The whole European-market path in one picture: Order first, link second, guest pays on an unauthenticated CDE page, status returns to the TD/CrD. The non-EU branch leaves at the market check and keeps the Go To Payment flow it has now. Dashed boxes are open questions, dashed edges are the decline and the retry.

TD/CrD TD Portal Enterprise Backend / Payment Service Email service Guest CDE-PaymentUI TrustPayments no yes approved declined Return to Payment Page, same session TD/CrD picks invoice or passenger, enters quantity, clicks Check Out Create excursion order and order items, unpaid, payment status NEW Q9 European market booking? Existing Go To Payment flow, unchanged Payment Information, EU variant: no CC address, no Do Not Send CC, Send Payment Link Pre-fill guest email from the client record Confirm or override the email per guest, format validated Generate token, tie it to the order, set expiry, build the URL, write the audit log Q1 Q2 Send the payment-link email Q8 Record delivered or bounced, shown on TDP Open the email, click the link Validate token: active, not expired, order unpaid Landing page, unauthenticated, CDE styling Q3 Enter card, Proceed to Payment Authorise card Return the result to the Payment Service Q7 Approved? Payment record FINISHED, transaction record, token deactivated, audit log Approved screen, Close ? Receipt email from GFOB: which sending system? Q4 Payment record ERROR, token deactivated, session kept open Declined screen: Return to Payment Page, or Close ? Status visible to TD/CrD: where in TDP? Q5 ? Payment status per departure: TDP view and Finance report Q10
Future state, European market. Lanes are systems; the flow runs left to right.

Numbered markers on the diagram (Q1, Q2, Q3, Q4, Q5, Q7, Q8, Q9, Q10) match the question table on the overview.

Facts

Assumptions to confirm in refinement

Open questions