SS-9200 is how delivery money moves: collect the fee + driver tip at checkout, hold it, remit to Uber (driver paid, incl. tip), then cover Uber's charge from the fee already withheld from the order total (delivery is customer-paid โ no merchant deduction). It's server-side plumbing โ its touchpoints are screens that already exist (checkout, report), so it builds no screen of its own.
The flow, per delivery
1Collect & hold. At checkout the customer pays subtotal + delivery fee + driver tip + tax (SS-9166); INFI holds the fee + tip (single central Uber account).
2Remit to Uber. When the delivery is created, INFI pays Uber for it โ the $3 tip is passed to the driver via Uber, not the merchant.
3Pickup = INFI location address. Sent to Uber as the pickup โ no Uber store is created, no matching.
4Cover Uber from the withheld fee. The customer paid the delivery fee on top of the order; INFI withholds that slice of the order total and covers Uber's charge from it โ no merchant payout deduction, no separate bill (SS-9174). See the breakdown below.
5Reverse on failure. Refund / cancel โ the held fee + tip are reversed (SS-9168).
The money, per delivery (customer-paid)
Line
Amount
Goes to
Delivery fee (customer pays on top)
$5.00
Uber (trip)
Driver tip (customer adds at checkout)
$3.00
Driver, via Uber
INFI withholds from the order total
$8.00
Held by INFI
Deducted from merchant payout
$0.00
โ
Why there's no screen
It's money plumbing โ the customer only sees the total at checkout (SS-9166); the merchant only sees the delivery fee & Uber cost per order in their report.
No one configures or monitors the flow in a dedicated screen โ its touchpoints already exist.
๐ตTips go to the driver, not the merchant โ the tip is collected at checkout, held by INFI, and remitted to Uber for the driver. A refund reverses the fee and the tip.