Multiple invoices per order


Add support for payments by installments and multiple payments. In this case we should add a new entity - "Invoice" (not the same as "Order"). like it's already done in magento. Make separate invoices for refunds, void, etc

See related work item #12525 (Payments by installments)


eadameg wrote Apr 19, 2012 at 5:57 PM

Take into account the following:
1) It maight be a minimum purchased amount to accept this payment method
2) There should be a formula to calculate the instalements. Example Pn=T/n * Kn where Pn is the monthly amount to pay when the Total (T) will be payed in n installments; and Pn is a factor to reflect the financial cost for thelaying payment in those n installments.
3) It is very common that the factor Pn will vary from bank (issuer bank of the card) to bank; so it might have to be enhaced to Pnb and the customer must select the bank.

rdaddis wrote Mar 13, 2013 at 3:57 AM

Google Products Feed Specification includes an installment attribute for Brazil only
Multiple Installments-Brazil Only
The attribute below only applies to feeds which target Brazil. It lets you specify an additional option for users to pay in multiple installments.
installment [installment] - Number and amount of installments to pay for an item.
This attribute is only available for feeds targeting Brazil.

zar wrote Jun 20, 2013 at 1:23 PM

Multiple payments would be great.
Let's imagine I have a custom plugin for special needs (gift card, loyalty card, ...) and "traditional" Nop payment plugins. Example: my client has to pay $100, he chooses to pay $75 with my custom plugin and $25 with Paypal.

scharada wrote Jun 20, 2013 at 2:21 PM

the ideal would be to have the following settings apply by store and possibly by vendor :
1 - minimum cart sub-total to apply downpayment ( should be applied to sub-total to make sure shipping by total and fees are paid on top of downpayment)
2 - minimum downpayment : either a % if > x or a flat amount if < X
3 - maximum number of payments allowed : number of installments to schedule
4 - if split payment is used : then maximum number of payment lines allowed . ie : total is plit over max of x payment methods .

hope this helps.

scharada wrote Jun 20, 2013 at 2:33 PM

another very important option is to specify if order can be shipped if total is not fully paid (of course except when the balance is going to be paid COD).
case 1: Down payment
order total = 1000 USD
down payment = 400 USD, balance due at delivery (COD).
shipping of not fully paid order is allowed
case 2: Installments
order total = 1000 USD
down payment = 400 USD,
balance due over 2 installments
shipping is not allowed until order is fully paid.

mmacarie32 wrote Oct 15, 2013 at 9:59 AM

Maybe this could address the issue when the user selects a payment method that requires redirection to the payment gateway, the order is placed but the payment is never completed and the Order remains in Pending forever because the user can't retry to pay using the selected payment method.

Also, if the user decides to add a new product to the order, then the user should be able to pay a difference using any of the available payment methods.

Each payment, related to the order should have it's own payment method.

sargent_rob wrote Jan 23, 2014 at 1:07 AM

In addition to everyone's valuable points perhaps we can consider the following behaviour:

When order value is established (e.g. $1000) and customer elects to pay in instalments, customer enters: payment frequency - monthly / fortnightly / weekly ( in this example - weekly )
  • 1st payment day (e.g. 20 March 2014)
  • last payment day (e.g. 22 April 2014)
  • payment method (e.g. Credit card or Direct Debit or Pay Pal etc) system will produce order payment plan by:
  • Calculating number of payments fitting between 1st and last payment days - ( in our example 5 instalments)
  • Adds to the order value ($1000) any transactional fees (if applicable) - for example each credit card payment attracts fee of 1.5% and we are passing it to the customer/ or it is flat fee of $0.50 per transaction
  • Calculates instalment amounts and payment days
  • Display this payment plan to the customer
To process these instalments we might require scheduled or manually triggered method where system:
  1. Identifies all non-processed instalments (for example since last run yesterday till today), creates list of items to be processed payments grouping them by payment method
  2. Submits each payment (with reference to the order/payment plan item) through appropriate gateway
  3. Updates each payment status as successful or declined if the response from payment gateway is instant. For the non-instant scenario we will require separate process/method to get response from gateway/API etc to update previously submitted payments statuses.
  4. Declined payment optionally attract fee (might be based on payment method) and this should be taken into account. If payment is declined system:
    a. Resets status as declined
    b. Records reason why payment is declined (there are quite a few in total)
    c. Recalculates all future payments in payment plan to "absorb" declined payment amount and optional declined payment fee
    Payment plan might be put "on hold" (or cancelled) automatically after X payments declined or some other reasons.
    Any changes to payment plan might require email notification to the customer.
Ideally customer has ability to:
  1. See all historical and future payments, successful and declined
  2. Change payment plan parameters: next payment day, last payment day, frequency, payment method
  3. Put payment plan on hold - this is optional, based on business model

itwizard wrote Jul 30, 2014 at 6:02 AM

Does anyone know when this "Proposed" status will changed to "Completed" ? :)