E-commerce
July 1, 2026
"I put in my gift card and my credit card, but the remaining balance to pay is not showing up." "My voucher doesn't cover everything, how do I pay the rest?" "On my order, how much was charged to each payment method?" Three tickets where an ill-explained split-tender cart blocks the checkout and generates a dispute.
The e-commerce multi-payment cart support covers combinations of gift card, credit, wallet, credit card, application order, remaining balance, and post-order allocation. Distinct from installment payments (#775): here, it is multiple payment methods on a single checkout.
This guide #987 deploys policy MULPAY-SUP, flow MP-1 to MP-8, and matrix MULPAY-MAP. Future customer service pair for multi-payment cart bot (#988).
Summary
Why do multi-payment carts generate tickets?
The customer combines a gift card, store credit, loyalty reward, and credit card on the same cart. The checkout displays a confusing remaining balance, rejects the combination, or charges an unexpected amount per method. Without MULPAY-MAP, the agent improvises the order of application or promises a split against policy.
Five typical split tender points of friction
Combination rejected: checkout does not accept two payment methods
Confusing remaining balance: customer does not see the credit card amount after applying store credit
Order of application: gift card before or after promotion
Order allocation: which amount is charged to each method post-purchase
Policy limit: maximum methods or credit card remaining minimum
Omnichannel beauty DTC example
Beauty brand with active gift card + store credit, 7 mulpay_/month tickets. After MULPAY-MAP: mulpay_resolution_rate 83%, mulpay_checkout_complete_rate +22% in 6 weeks.
MULPAY #987 vs SPLITPAY #775, gift card, store credit, BNPL and bot #988
Seven basket payment contents, seven distinct angles.
Quick Matrix
#987 MULPAY: split tender basket, gift card, credit note, wallet, credit card, same checkout
SPLITPAY #775: staggered direct debits, distinct merchant, combined payment methods, checkout
GIFTCARD: gift card only, distinct remaining balance/expiration, multi-method combination
STORECREDIT: credit note, distinct refund, split tender policy
LCARD #587: loyalty wallet, distinct points, combined checkout credit
#775 = scheduled debits over time. #987 = multiple payment methods on an immediate checkout.
Promise #987
MULPAY-SUP policy, MULPAY-GATE tree, 8 macros, split tender registry, mulpay_resolution_rate KPI.
Which mulpay_* typologies should be classified?
Action-oriented classifier: combination ≠ balance ≠ order ≠ distribution ≠ limit.
Eight MULPAY-MAP Typologies
mulpay_split_tender_explain: how to combine checkout methods
mulpay_giftcard_plus_card: gift card + credit card for remaining balance
mulpay_store_credit_apply: store credit + other method
mulpay_wallet_partial: loyalty wallet credit partial cart
mulpay_remaining_balance: remaining amount after applying credit
mulpay_order_split_status: distribution of amounts by order method
mulpay_limit_exceeded: combination out of policy limits
mulpay_ops_flag: ops signal sync payment policy stack
Tags: mulpay, split_tender, multi_payment, combined_checkout. MULPAY-MAP-GROUNDED: split_policy_copy apply_order_copy from registry only.
MULPAY-SUP Policy: agent rules and split tender registry
The MULPAY-SUP policy sets multi-payment responses without invented combinations outside of the map.
Six MULPAY-SUP rules
MULPAY-REGISTRY-FIRST: check MULPAY-MAP before split response
SPLIT-POLICY-CITE: cite split_policy_copy allowed_methods map
APPLY-ORDER-CITE: cite apply_order_copy application order map
ORDER-VERIFY: lookup order_ref transactions before distribution
NO-COMBO-INVENT: no promise combination outside of registry
Handoff #988: brief multi-payment cart widget bot
Minimum split tender registry
mulpay_id: multi-payment policy row identifier
allowed_methods_ref: card gift_card store_credit loyalty_wallet
split_policy_copy: combination rules text agents
apply_order_copy: application order of checkout methods
min_card_remainder_ref: card minimum if partial credit
stacking_rules_copy: cumulative promo gift card store credit
remaining_balance_formula_copy: remaining balance map calculation
checkout_help_url: multi-method checkout help
Flow MP-1 to MP-8: multi-payment basket ticket processing
Eight steps: intake lookup verify classify respond guide split order log close.
Flow MP-1 to MP-8
MP-1 Intake: mulpay_* intent + order_ref mentioned methods
MP-2 Policy lookup: MULPAY-REGISTRY allowed_methods
MP-3 Balance verify: gift card store credit wallet live balance
MP-4 Classify: combo remaining order split limit
MP-5 Respond: macro MULPAY grounded split apply
MP-6 Checkout guide: apply_order steps remaining balance
MP-7 Order split: transactions distribution by method
MP-8 Log: KPI mulpay + brief registry correction
SLA: mulpay_remaining_balance explained with remaining_balance_formula in a single interaction.
Eight MULPAY-* macros ready to paste
Split tender macros without invented non-registry combinations.
MULPAY-* Library
MULPAY-SPLIT-01: "Combinable methods: {{allowed_methods_ref map}}. {{split_policy_copy map}}."
MULPAY-ORDER-01: "Application order: {{apply_order_copy map}}."
MULPAY-REMAIN-01: "Remaining balance: {{remaining_balance_formula_copy map}}. Cart {{cart_total}} minus applied credits."
MULPAY-GC-CARD-01: "Gift card then Bank card: {{apply_order_copy map}}. Bank card minimum: {{min_card_remainder_ref map}}."
MULPAY-CREDIT-01: "Store credit: {{store_credit solde}}. Complete with {{moyen autorisé map}}."
MULPAY-STATUS-01: "Order {{order_ref}}: {{répartition transactions par moyen}}."
MULPAY-LIMIT-01: "Unauthorized combination: {{split_policy_copy map}}. Alternative: {{moyen seul map}}."
MULPAY-DONE: "Receipt summary {{id}}. Resolution: {{résolution}}."
MULPAY-GATE tree and payment ops coordination
Decision tree before allowing out-of-map combinations or dead-end checkouts.
MULPAY-GATE
Methods mentioned? → lookup MP-2 balance verify
How to combine? → SPLIT-01 ORDER-01 split_policy apply_order
Remaining balance? → REMAIN-01 remaining_balance_formula
Gift card + Credit card? → GC-CARD-01 min_card_remainder
Partial store credit? → CREDIT-01 store_credit complement
Post-order distribution? → STATUS-01 order transactions
Staggered direct debits? → reroute SPLITPAY #775
BNPL financier? → reroute BNPL
Payment stack launch ritual Day-0
Ops publishes MULPAY-MAP: allowed_methods tested, apply_order validated, stacking_rules shared with support. Bot #988 sync go-live.
KPI, QA and handoff to bot #988
Measuring MULPAY detects rejected combinations without guidance and poorly explained distributions.
Five MULPAY KPIs
mulpay_resolution_rate: tickets resolved without ad hoc invented combos
mulpay_checkout_complete_rate: completed multi-means checkouts / attempts
mulpay_remain_cite_rate: % REMAIN-01 tickets remaining balance provided
mulpay_limit_ticket_rate: mulpay_limit_exceeded tickets / split attempts
mulpay_combo_invent_violation: invented combinations outside target map 0
Handoff #988
Export MULPAY-MAP to bot: mulpay_split_tender_explain mulpay_remaining_balance mulpay_giftcard_plus_card prioritised. Guardrail SPLIT-POLICY-CITE brief #988: bot cites split_policy_copy apply_order map only.
Edge cases: gift card only, cart calculation, stacked promos, failed payment
Four cases outside the standard multi-payment flow.
Gift card alone without combination
GIFTCARD reroutes gift card if ticket balance expiration is not split.
Total cart error before split
CARTCALC alignment cart calculation if total is incorrect before credits.
Promo + gift card accumulation
STACKING-01 stacking_rules_copy map cited before blaming client.
Bank card declined after credit applied
PAYDECL reroutes declined payment if credit is OK but bank card fails.
Agent training: 20 minutes MULPAY
Module: MULPAY-REGISTRY, distinguish SPLITPAY #775 GIFTCARD STORECREDIT BNPL bot #988.
Exercises
Ticket A: gift card + credit card → GC-CARD-01 REMAIN-01
Ticket B: partial store credit → CREDIT-01 apply_order
Ticket C: order distribution → STATUS-01 transactions
Ticket D: combination declined → LIMIT-01 split_policy
How Qstomy integrates MULPAY into your stack
Qstomy on Shopify: mulpay_* route, split tender registry sync, SPLIT REMAIN STATUS macros and handoff #988 split policy grounded gate.
Three bricks
Routing: intent split_tender vs installment vs gift_card_solo
Multi-pay registry: allowed_methods apply_order stacking
Bot #988: tier 1 options limit status widget
Scenario: DTC beauty gift card + store credit. Registry D-0. mulpay_resolution_rate 83%, checkout_complete_rate +22%.
Explore AI support and request a demo.
FAQ and MULPAY deployment checklist
FAQ
Allow out-of-map combination?
No. NO-COMBO-INVENT. LIMIT-01 quotes official split_policy.
Difference from SPLITPAY #775?
#775 = debits scheduled over time. #987 = multiple methods in the same checkout.
Difference from gift card alone?
Gift card = balance with usage expiration. #987 = combination with another method.
Difference from BNPL?
BNPL = third-party financer. #987 = split tender in-store checkout.
Difference from #988?
#987 = agents verify transactions ops limit. #988 = bot tier 1 options widget.
MULPAY Deployment Checklist (8 steps)
MULPAY-SUP + MULPAY-MAP: split tender registry template
allowed_methods_ref: each checkout combination tested
apply_order_copy: validated by payment legal ops
stacking_rules_copy: promo, gift card, and credit note stacking
min_card_remainder_ref: documented if partial credit
checkout_help_url: multi-method help page live
Sync bot #988: SPLIT-POLICY-CITE
20-min Training: section 10 exercises
Linking
Enzo
July 1, 2026
