Explore · area summary
43 cards in the blueprint's section Payment: 33 are in Lean, 3 are open questions and 10 need a business decision.
The number of times a card here uses a card in that area.
The number of times a card in that area uses a card here.
Each with the number of cards that depend on it, directly or through other cards, most first. Click one to see what it depends on and what builds on it.
An order item with nothing to pay goes ahead when the seller commits to pay zero.
Open point: the source does not say which delivery status the item's services move to.
51 cards depend on it, directly or through other cards, in 7 areas.
A refund goes back to the payment methods that paid.
Open point: the source does not say how a refund is split across several methods, or whether surcharges are refunded. If surcharges are refunded, a refund can exceed the item's price, which bears on the open question about refunds and payments.
7 cards depend on it, directly or through other cards, in 2 areas.
Every order item that is unpaid or partly paid carries a payment time limit, and a paid item carries none. A time limit of zero on an offer item means the item must be paid when the order is created. Case to check: An order created without payment returns no time limit for one item. Under the second reading that item never expires and holds its seat with nothing paid. In the model the guarantee is that an unpaid item does not stay in the order indefinitely. That a paid item has no time limit is a theorem of the outcome rule.
Counterexample: an order whose trip was created without a payment time limit still holds the trip a year later, its flights confirmed and nothing paid.
Open point: The ARMI guidance expects the airline to set a limit on every unpaid item, while the EASD Time Limits page says a missing limit only means no advice was given. The business must decide whether an unpaid item may exist without a limit and, if so, whether it can stay unpaid indefinitely.
1 card depends on it, directly or through other cards, in 1 area.
When one payment with several methods covers several order items, the airline decides how much of each method goes to each item and the seller has no say. A seller who wants a fixed split sends one payment per item. Case to check: Items of 800.00 and 100.00 are paid with 400.00 by settlement plan and 500.00 by card. If the 100.00 item is cancelled, its refund goes to the card under one allocation and to the settlement plan under another.
Open point: The source gives the airline the allocation and states no rule for it. The business must fix the rule, because it decides which method is refunded when one of the items is later cancelled.
No card depends on it yet.
The payment catalogue places each accepted method in one or more groups, and two methods may be combined in one payment when they share a group. The airline refuses a payment that combines methods it does not accept together. Case to check: Method A is in groups 1 and 2, B in groups 2 and 3, and C in groups 1 and 3. Every pair shares a group, but no group holds all three.
Open point: The source defines combinability for pairs only. The business must decide whether three or more methods need one group that holds them all or only a shared group for each pair.
No card depends on it yet.
The airline accepts a payment for an order item only before the item's payment time limit and, when the item has a price guarantee, before that guarantee expires. A payment attempted after the price guarantee has expired fails with a price guarantee error. Case to check: The airline extends an item's price guarantee two days past its payment time limit, which the source allows. The item can no longer be paid while its price is still guaranteed.
Open point: The payment time limit part is clear, but for the price guarantee the source also says repricing is only recommended. The business must decide whether an expired guarantee blocks payment or only lets the airline change the price, and whether a guarantee may outlast the payment time limit, which the source says it should not.
No card depends on it yet.
A voucher is a payment method that spends value the airline holds for the payer, alone or combined with other methods. Value stored as an order item can be spent in another order only after the airline issues it as a voucher. Case to check: An 800.00 item is paid with a 300.00 voucher and 500.00 by card, then cancelled with a 100.00 penalty. Refunding the card first returns 500.00 to the card and 200.00 to the voucher; a pro rata split returns 437.50 and 262.50.
Open point: The voucher capability has no guidance beyond its name. The business must decide whether a voucher can be partly spent, whether it expires, and whether a refund of a voucher paid amount goes back to the voucher or to another method.
No card depends on it yet.
When the airline has quoted a precise surcharge for a stated card brand and card type, the payment must use that brand and type and is charged that surcharge. A payment with a different brand, scheme, or consumer or commercial card type fails with a mismatch error. Case to check: The offer is priced with a 3.00 surcharge for a consumer Visa debit card, and at payment the airline charges 5.00 for the same card. Nothing in the source forbids it.
Open point: The mismatch errors exist, but no page says a quoted surcharge binds the airline, and the catalogue calls its ranges estimates. The business must decide whether the charged surcharge may differ from the quote or fall outside a published minimum and maximum.
No card depends on it yet.
A refund appears in the order as a payment transaction of its own, with a new payment ID, a negative amount, a payment method and its own status. In the worked examples the method is the one that paid, but the record does not point to the payment it returns. Case to check: An order holds a 1000.00 settlement plan payment. Cancelling it adds a payment of minus 1000.00 with its own ID and no reference to the first.
Open point: The source does not link a refund to the payment it reverses, while our model attaches each refund to one payment. The business must decide whether to keep that link; without it the per payment limit in the open refund question cannot be checked and only an order level limit remains.
No card depends on it yet.
Each payment surcharge carries an indicator saying whether it is refundable. A refund of an item's payment returns a surcharge only when its indicator marks it refundable. Case to check: A 100.00 item is paid with 20.00 by settlement plan and 82.00 by card, including a non-refundable 2.00 surcharge. A full refund of 102.00 returns the surcharge, while the cap under the indicator is 100.00.
Open point: The indicator appears in every simulation example, always marked non-refundable, and no page says how a refund uses it. The business must decide whether the indicator binds refunds; with refundable surcharges a refund can exceed the item's price, which bears on C-17 and the open refund question.
No card depends on it yet.
An order item removed at its payment time limit holds no value: none of its services holds value afterwards.
Counterexample: when the removed trip's services become EXPIRED, the trip stays active under the cautious reading of the guide, where an expired service holds value. When they become REMOVED HOLD VALUE it stays active under every reading. With REMOVED it is cancelled under both readings.
Open point: which service status and delivery status an item takes when its payment time limit passes unpaid, and whether it then holds value.
No card depends on it yet.
After a payment fails, its items stay unpaid with services and time limits unchanged, and the seller may try again in a new payment transaction before the time limit. The error tells the seller whether to correct the card details, add payer authentication, use another method, or stop; after a hard stop the airline accepts no payment from that payer. Case to check: A payer flagged for suspected fraud on one order pays for a second order with the same card. The source does not say whether the stop carries over.
Open point: The source calls recovery optional and does not say whether the airline must accept a retry. The business must decide how many retries are allowed, whether a hard stop applies to the payer, the order or the method, and whether the order is then cancelled.
No card depends on it yet.
A SUCCESSFUL or FAILED payment keeps its status whatever outcome the airline later reports for one of its methods.
Counterexample: under a reading where a card chargeback turns a successful transaction into a failed one, a card payment for the trip goes from SUCCESSFUL to FAILED. Under a reading where a late redirected payment is recorded, a payment the airline marked FAILED at the time limit becomes SUCCESSFUL a minute later, while the trip it paid for stays removed.
Open point: whether a SUCCESSFUL payment can later fail, whether a FAILED payment can later succeed, and what then happens to the order items it covers.
No card depends on it yet.
An open guarantee fails under some reading of the sources. For these, Lean proves a version under one reading, named
with _of_. The model leaves the choice of reading to the business.
Open point: which service status and delivery status an item takes when its payment time limit passes unpaid, and whether it then holds value.
Lean proves the guarantee for one reading of the sources. If the business settles the question this way, it holds for every input:
When the removal cancels a removed item's services as REMOVED, and the delivery status table lets each of them be removed, none of them holds value, under every reading of the guide.
Proven as removed_item_holds_no_value_of_removed; open as removed_item_holds_no_value.
The requirements whose rules or guarantees are on this area's cards. Each opens its chapter in the review document.
| ID | Requirement | Rule | Acceptance criteria |
|---|---|---|---|
| ONE-301 | Paying with several methods | The system shall give a payment the status FAILED if it has no payment method or the transaction of any of its payment methods failed, SUCCESSFUL if all of them succeeded, and PENDING otherwise. | 4 proven |
| ONE-302 | Paid order item | The system shall count an order item paid once a SUCCESSFUL payment covers it. | 3 proven |
| ONE-303 | Payment status and its moves | When the airline reports the outcome of a payment method's transaction, the system shall record it as the transaction's status if the move from the recorded status is allowed. | 2 proven · 1 open |
| ONE-304 | Accepting a payment | When a seller pays for order items, the system shall accept the payment only if it is made before the items' payment time limits and its requested amounts add up to their price, and shall charge each payment method its requested amount plus its surcharge. | 7 proven |
| ONE-305 | Applying a payment outcome | When a payment becomes SUCCESSFUL, the system shall move every CONFIRMED service of the order items it covers to READY TO PROCEED and remove their payment time limits. | 5 proven |
| ONE-306 | Unpaid item at its time limit | When an order item's payment time limit passes with no SUCCESSFUL payment covering it, the system shall remove the item and mark FAILED every PENDING payment that covers it. | 4 proven · 2 open |
The capabilities of IATA's Airline Retailing Maturity Index that this area's candidate cards belong to. The codes and names are IATA's.
PAYMIX Pay Using Mixed Payment Instruments10 cards here. Show every card with PAYMIX · IATA's pagePAYORD Pay for an Existing Unpaid Order or Order Items7 cards here. Show every card with PAYORD · IATA's pagePAYRCV Payment Recovery4 cards here. Show every card with PAYRCV · IATA's pagePAYSUM Payment Transaction Summary4 cards here. Show every card with PAYSUM · IATA's pageORDWPM Create Order Without Payment3 cards here. Show every card with ORDWPM · IATA's pagePAYCPC Pay Using Customer Card3 cards here. Show every card with PAYCPC · IATA's pagePAYGTW Pay Using Payment Gateway3 cards here. Show every card with PAYGTW · IATA's pagePAYREF Refund Amount for Any Change to an Order3 cards here. Show every card with PAYREF · IATA's pageORDDEL Order Notification for Fulfillment of Services with no Tickets and EMDs1 card here. Show every card with ORDDEL · IATA's pagePAY3D2 Seller Authenticates Payer (3D-Secure v2)1 card here. Show every card with PAY3D2 · IATA's pagePAYSET Pay Using Settlement Platform1 card here. Show every card with PAYSET · IATA's pagePAYVCH Pay Using Vouchers1 card here. Show every card with PAYVCH · IATA's page