[P07] Pay for an Entry or Membership
Summary
After enrolment the entrant pays for the order. EMS owns the order; the payment provider (today the site’s own store, later EMS itself) takes the payment and reports the outcome to EMS.
Actor & Context
Actor: Entrant
Frequency: Once per order
Precondition: An order created by EMS at the end of enrolment
Entry point: The portal’s order page, Pay
Main Flow
-
The portal asks EMS to start payment for the order.
-
EMS asks the payment provider for a payment page; the entrant pays there.
-
The provider reports the outcome to EMS with its transaction reference; EMS marks the order and its entries paid and sends confirmation.
Alternative Flows
-
AF-1: Entrant returns to the payment page: the same transaction is reused, not a new one.
-
AF-2: Card declined: the order stays unpaid and the entrant can try again.
-
AF-3: Entrant abandons: the order stays unpaid; EMS’s own rules decide when it lapses.
-
AF-4: Order cancelled at the provider: the provider reports it and EMS cancels the order, recording when.
-
AF-5: Payment message fails its authenticity check: nothing changes; the operator is told.
-
AF-6: Late or repeated message for a paid order: nothing changes.
Acceptance Criteria
-
A paid order is never moved back automatically (PS-PY-02)
-
One transaction per order (PS-PY-04)
-
State changes reach EMS within a minute, with the transaction reference (PS-PY-05)
-
Removing the store does not change the entrant’s journey apart from the payment page (PS-PY-13)
API Surface
The calls below are named by purpose; their exact form is defined in the public site design.
| Call | Purpose |
|---|---|
Portal to admin-service: start payment for an order |
Returns the payment page |
admin-service to provider: create payment |
Provider-specific |
Provider to admin-service: payment outcome |
Order status and reference |
Design Anchors
-
Public Site Requirements — PS-PY-01 to 05, PS-PY-10 to 13