MF - SIP payment variations

[char-star]

SIP w/o mandate registration (manual payments)

one fulfilment of type SIP. No payment involved in here, order gets accepted. Instalments get generated with no payments. Buyer app asks for a new payment (similar to payment failure retry cases) and pays for the instalment.

For delayed/ no payments, have a separate payment mode called no_payment and use that so there is an explicit mention of no payment in the order contract.

SIP w/o mandate registration (delayed mandate registration)

one fulfilment of type SIP. No payment involved, order gets accepted. Manual payments are made by default. Later, buyer app can make a update call to the parent sip order and ask for register mandate pg link (similar to payment failure retry case) and registers the mandate. After that the instalments are generated with mandate debit payment type

SIP w/ ability to update a mandate (in case previous mandate expired/change of bank a/c)

Same as delayed mandate registration capability

SIP w/ immediate first instalment payment

Option 1: one fulfilment of type sip with an option to set first instalment payment. Payment option is generated which will collect onetime payment + mandate creation together.
Option 2: (only possible if sip can be registered w/o mandate) fulfilment of type sip with an option to set first instalment generation and no mandate. SIP gets registered and first instalment is automatically generated with multiple payment options - buyer can choose a payment option and pay for the instalment

[char-star]

• for sip installment, asking for a new payment - buyer app will not know the payment options available - how can he call for a payment mode? Should we think of an ability to fetch the available payment options to be able to choose one?

• for skip payment mode, should we use status deferred or delayed or something else instead of paid? skip_payment mode is explicitly needed because to keep it consistent with other flows in which payment has to be done pre-fulfillment for the sip to start working - with that logic paid status makes sense actually?

• for sip update mandate flow: when asking for a mandate registration link, in the on_update response, there will be two payment objects, earlier payment in either mandate_registration paid state or skip_payment in deferred state and one payment for the new mandate registration link. How will the seller app or buyer app understand that the earlier mandate will not be used and new one will be used going forward? Can't determine it with statuses.