Skip to content

Payment Processing and VAT Calculation

User Scenarios & Testing

User Story 1 - Initial Stand Configuration Payment (Priority: P1)

A sponsor configures their exhibition stand by selecting package options and add-ons. They need to see the total cost including VAT and complete payment to confirm their booking.

Why this priority: This is the core payment flow that enables the business to collect revenue. Without this, no bookings can be confirmed.

Independent Test: Can be fully tested by creating a stand configuration, verifying the calculated total (base cost + VAT), and completing a card payment. Delivers immediate value by enabling bookings.

Acceptance Scenarios:

  1. Given a sponsor has selected a stand package and add-ons, When they view the checkout summary, Then they see itemised costs, VAT amount, and total due
  2. Given a sponsor is ready to pay, When they click the payment button, Then they are directed to a secure card payment interface
  3. Given a sponsor completes payment successfully, When the payment is confirmed, Then they receive a receipt showing all items purchased and amounts paid
  4. Given payment fails, When the error occurs, Then the sponsor sees a clear error message and can retry payment

User Story 2 - Balance Payment for Configuration Changes (Priority: P1)

After initial booking, a sponsor modifies their stand configuration by adding or removing items. They need to pay any outstanding balance or receive information about refunds.

Why this priority: Configuration changes are a core feature differentiator for v2. Without balance payments, sponsors cannot modify bookings post-payment.

Independent Test: Can be tested by modifying an existing paid configuration, verifying the balance calculation (new items minus removed items), and completing a balance payment. Delivers value by enabling flexible booking modifications.

Acceptance Scenarios:

  1. Given a sponsor with a paid booking before the modification cutoff deadline, When they add new items to their configuration, Then they see the additional cost and can proceed to pay the balance
  2. Given a sponsor modifies their configuration, When they view the payment summary, Then they see what changed (e.g., "Added: 2 stools - £40.00") with the incremental VAT and balance due
  3. Given a sponsor removes items from their configuration, When they review changes, Then they see the credit amount and information about refund processing
  4. Given a sponsor completes a balance payment, When payment succeeds, Then they receive an updated receipt showing the modification details and new total paid
  5. Given the modification cutoff deadline has passed, When a sponsor attempts to modify their configuration, Then they see a message indicating modifications are no longer allowed
  6. Given a sponsor has made multiple configuration changes, When they view their balance due, Then they see a single cumulative total reflecting all unpaid modifications
  7. Given a sponsor with multiple unpaid changes, When they complete balance payment, Then all accumulated changes are paid in one transaction and receipt shows all modifications
  8. Given VAT rules have changed since initial payment, When a sponsor pays balance, Then the system applies the current VAT rate to the balance payment (not the original rate)

User Story 3 - International VAT Calculation (Priority: P2)

Administrators configure VAT rules based on company and event locations. The system automatically applies the correct VAT rate when sponsors checkout.

Why this priority: VAT compliance is legally required but can be configured once and works automatically. Less urgent than core payment flows.

Independent Test: Can be tested by configuring VAT rules for different location combinations, then verifying correct rates are applied during checkout for various sponsor/event scenarios.

Acceptance Scenarios:

  1. Given an administrator, When they configure VAT settings, Then they can define VAT rates for different combinations of sponsor location and event location
  2. Given configured VAT rules exist, When a UK sponsor books for a UK event, Then the system applies the UK VAT rate to their checkout
  3. Given configured VAT rules exist, When an EU sponsor books for a UK event, Then the system applies the appropriate cross-border VAT rate
  4. Given no VAT rule matches, When a sponsor attempts checkout, Then the system applies a default rate and logs a warning for administrator review

Edge Cases

  • How does the system handle partial refunds when sponsors remove some but not all items?
  • How does the system handle currency conversion for international events?
  • What happens if a sponsor's configuration change results in a negative balance (refund due)?
  • What happens if a sponsor attempts to modify configuration after the cutoff deadline?
  • How does the system communicate VAT rate changes to sponsors before balance payment?

Requirements

Functional Requirements

  • FR-001: System MUST calculate total amount due based on selected stand package, add-ons, and configuration items with their individual prices
  • FR-002: System MUST apply the correct VAT rate based on sponsor company location and event location as configured by administrators
  • FR-003: System MUST display itemised breakdown showing base costs, VAT amount, and total due before payment
  • FR-004: System MUST integrate with card payment processing to collect payment securely
  • FR-005: System MUST generate a receipt showing all purchased items, quantities, individual costs, VAT, and total paid
  • FR-006: System MUST detect when a sponsor modifies their stand configuration after initial payment
  • FR-007: System MUST calculate the balance due when configuration changes, accounting for added and removed items
  • FR-008: System MUST display configuration changes in human-readable format on receipts (e.g., "Added: 2 stools", "Removed: 1 display screen")
  • FR-009: System MUST allow sponsors to complete balance payments for configuration changes
  • FR-010: System MUST generate updated receipts showing modification details, previous payments, balance paid, and new total
  • FR-011: Administrators MUST be able to configure VAT rates for different combinations of sponsor location and event location
  • FR-012: System MUST store VAT configuration as part of event settings
  • FR-013: System MUST handle payment failures gracefully and allow sponsors to retry
  • FR-014: System MUST prevent duplicate payments for the same balance
  • FR-015: System MUST track payment history for each booking, including initial payment and all balance payments
  • FR-016: System MUST handle refund scenarios when sponsors remove items (credit or refund process to be defined by business policy)
  • FR-017: Administrators MUST be able to set a modification cutoff deadline for each event (e.g., 14 days before event date)
  • FR-018: System MUST prevent sponsors from modifying stand configurations after the cutoff deadline has passed
  • FR-019: System MUST display clear messaging to sponsors when modification deadline is approaching or has passed
  • FR-020: System MUST accumulate all unpaid configuration changes into a single cumulative balance
  • FR-021: System MUST allow sponsors to make multiple configuration changes before paying the accumulated balance
  • FR-022: System MUST process cumulative balance payments in a single transaction
  • FR-023: System MUST display all unpaid configuration changes when showing balance due to sponsors
  • FR-024: System MUST apply the current VAT rate at the time of balance payment, not the original rate from initial booking
  • FR-025: System MUST recalculate VAT on balance payments using current VAT rules when balance payment is made
  • FR-026: Receipts MUST show which VAT rate was applied to each payment transaction
  • FR-027: System MUST allow concurrent modifications to booking configurations without locking
  • FR-028: When concurrent modifications occur, system MUST save the most recent change, overwriting previous unsaved changes

Key Entities

  • Booking: Represents a sponsor's exhibition booking with associated stand configuration and payment status
  • Stand Configuration: The selected package, add-ons, and items that make up the sponsor's exhibition stand; last saved version is authoritative
  • Configuration Item: Individual purchasable elements (packages, add-ons, furniture) with prices
  • Payment: A completed financial transaction including amount, VAT, timestamp, payment method reference, and VAT rate applied at time of payment
  • Receipt: A record of payment showing itemised breakdown, configuration changes (if applicable), totals, and VAT rate used
  • VAT Rule: Configuration defining VAT rate for specific combinations of sponsor location and event location
  • Configuration Change: A modification to an existing booking, tracking added and removed items with cost implications; multiple unpaid changes accumulate into cumulative balance
  • Event: Includes modification cutoff deadline timestamp

Success Criteria

Measurable Outcomes

  • SC-001: Sponsors can complete initial stand configuration and payment in under 5 minutes
  • SC-002: 95% of payment transactions complete successfully on first attempt
  • SC-003: System correctly calculates and applies VAT for 100% of bookings based on configured rules
  • SC-004: Sponsors can view and understand configuration changes and balance due without contacting support
  • SC-005: System processes balance payments within 3 seconds of payment gateway confirmation
  • SC-006: Receipts clearly show itemised costs and configuration changes, reducing payment-related support queries by 60%
  • SC-007: Administrators can configure VAT rules for new event/location combinations in under 2 minutes
  • SC-008: Zero payment processing errors due to incorrect VAT calculation
  • SC-009: Payment failure recovery rate (successful retry) exceeds 80%
  • SC-010: Zero sponsors able to modify configurations after cutoff deadline enforcement
  • SC-011: Sponsors can make multiple configuration changes and pay cumulative balance in single transaction without confusion
  • SC-012: System correctly applies current VAT rate to 100% of balance payments, regardless of original rate

Assumptions

  • Card payment processing will be handled by an external payment gateway (Stripe mentioned in description)
  • Prices for stand packages and add-ons are managed elsewhere in the system
  • Sponsor company location and event location data already exists in the system
  • VAT rules can change over time and balance payments use the current rate at time of payment
  • Currency for all payments is consistent per event (single currency per event)
  • Business will define the refund process policy separately (immediate refund, credit note, manual process)
  • Payment gateway integration supports both full payments and incremental balance payments
  • Receipt generation and delivery method (email, PDF download) already exists in the system
  • Administrators have access to a settings area where VAT configuration can be managed
  • Payment gateway timeouts and unavailability are handled by the external payment service (Stripe Checkout)
  • Modification cutoff deadline is set per event by administrators and applies to all sponsors for that event
  • Sponsors can make unlimited configuration changes before paying cumulative balance (no limit on number of unpaid changes)
  • VAT rate changes between payments are acceptable and legally compliant (each payment uses rate applicable at its time)
  • Concurrent modifications to the same booking are rare enough that last-save-wins approach is acceptable
  • Lost changes due to concurrent modifications are acceptable business risk (no conflict detection or recovery needed)

Dependencies

  • Stand configuration system (items, packages, add-ons with prices)
  • User and company management (to identify sponsor location)
  • Event management (to identify event location and modification deadline)
  • Payment gateway integration capability
  • Receipt generation and delivery system
  • Email notification system for payment confirmations

Out of Scope

  • Payment gateway failure handling and retry mechanisms (delegated to Stripe Checkout)
  • Refund processing workflows (handled separately)
  • Payment methods other than card (invoice, bank transfer, etc.)
  • Multi-currency support
  • Payment plans or instalments
  • Discount codes or promotional pricing
  • Tax compliance reporting
  • Payment gateway selection or switching
  • Historical VAT rate changes for past bookings (already paid)
  • Notification system for upcoming modification deadlines
  • Notification system for VAT rate changes
  • Concurrent edit conflict detection or resolution
  • Edit locking mechanisms
  • Change history tracking for concurrent modifications