Payment — Overview
Payment is the domain for collecting money and managing payment methods: PayLater, PayNow/Windcave, Direct Debit/Kiwi, Deposit, payment settings, and availability.
Payment does not create invoices; it uses Finance's invoice/billing/payment option to decide how a customer pays, which provider processes the transaction, and how the payment result is recorded.
Quick mental model
What Payment covers
| Area | One line |
|---|---|
| Payment method settings | Enable/disable methods by BU/site/category and configure the provider. |
| PayLater | Let booking continue with a pending payment or manual follow-up state. |
| PayNow/Windcave | Card checkout, redirect/notification URL, webhook/result and status message. |
| Direct Debit/Kiwi | Create customer token, batch debit, BU scoping and provider sync. |
| Deposit | Collect a partial amount before confirming the booking, using lock/eligibility to prevent double submit. |
| Zero-amount checkout | Total = 0: bypass the provider, use Proceed/Submit to auto-confirm or keep pending. |
| PayLater display name | Admin sets the consumer-facing PayLater display name at BU level; fallback "Pay Later". |
| Change Payment Method | Booking Manager changes a billing's payment option between Direct Debit and Other. |
| Success message settings | Admin composes method-specific rich-text success messages for Pay Now, Deposit, Direct Debit, Pay Later. |
| Checkout success surfaces | Screens/messages after payment by method and provider result. |
Reading order
Related
- Booking calls checkout in the submit/confirm flow.
- Finance owns invoice/billing/payment option on documents.
- Master Data supplies BU/account/attendee/site scope for payment.
- Subscription calls checkout in the submit/confirm flow.
Current implementation
- A Pay Now booking invoice uses the payment date so the payment applies immediately to the correct invoice; the processing lock is released when payment settles.
- Xero overpayment is recorded only when the provider confirms there is no invoice room; the remainder uses the BU overpayment account code and the rest of the batch continues through the Xero result.
- Netcash on a Tux site settles into the correct Tux payment batch; callback/result handling is idempotent.
Real-world example: A batch overpays two invoices. → Apply available room first, send the remaining amount through Xero and record only provider-confirmed overpayment under the BU account code.