sktan Posted July 6, 2015 Report Posted July 6, 2015 I've found a bug where invoice numbers don't seem to match the ones being paid for. i.e I press "Pay" for Invoice #79, it takes me to /invoice/pay/80 and the Gateway pays for invoice 80 leaving invoice #79 unpaid. Not too sure how I got that to occur, but any payments have been made successfully for Invoice #80 but invoice #79 remains unpaid for. Open Invoices: Pay URL + UI: Result:
Michael Posted July 6, 2015 Report Posted July 6, 2015 The 80 is the database ID, the invoice ID is a static ID no relation to the url.I have LC-yearnumber for my Invoice ID's they won't show that number in the url. or it would be: pay/method/2015092 for example. Not a bug in my opinion.
sktan Posted July 6, 2015 Author Report Posted July 6, 2015 The 80 is the database ID, the invoice ID is a static ID no relation to the url. I have LC-yearnumber for my Invoice ID's they won't show that number in the url. or it would be: pay/method/2015092 for example. Not a bug in my opinion. Hmm, Okay. Although when I pay for the invoice, it seems all good according to logs but the payments aren't being applied to that particular invoice I've paid for.
Michael Posted July 6, 2015 Report Posted July 6, 2015 Hmm, Okay. Although when I pay for the invoice, it seems all good according to logs but the payments aren't being applied to that particular invoice I've paid for. It could be a callback issue for the gateway but we'll need a dev to help confirm that and a way to fix it.
Tyson Posted July 6, 2015 Report Posted July 6, 2015 As Licensecart mentioned, the "Invoice #" is a formatted number which does not necessarily correlate to the system's invoice ID, which your gateway references. The system-level invoice ID can be seen in the URL when clicking the Pay link. My guess is the system-level invoice ID is "80" and the formatted invoice # is "79". You can update the format of the invoice number under [settings] -> [billing/Payment] -> [invoice Customization] -> "Invoice Format". I see you're using a "Stripe JS" gateway. Is that your custom gateway? In your first screenshot, I see that the transaction has not been applied to any invoice. If a payment was made successfully, the invoice should be marked paid, however, the non-merchant gateway determines the invoice and amounts to pay toward it. I would guess that the gateway has a bug or has not been fully implemented to pay specific invoices even though it does successfully take payment. Michael 1
sktan Posted July 6, 2015 Author Report Posted July 6, 2015 As Licensecart mentioned, the "Invoice #" is a formatted number which does not necessarily correlate to the system's invoice ID, which your gateway references. The system-level invoice ID can be seen in the URL when clicking the Pay link. My guess is the system-level invoice ID is "80" and the formatted invoice # is "79". You can update the format of the invoice number under [settings] -> [billing/Payment] -> [invoice Customization] -> "Invoice Format". I see you're using a "Stripe JS" gateway. Is that your custom gateway? In your first screenshot, I see that the transaction has not been applied to any invoice. If a payment was made successfully, the invoice should be marked paid, however, the non-merchant gateway determines the invoice and amounts to pay toward it. I would guess that the gateway has a bug or has not been fully implemented to pay specific invoices even though it does successfully take payment. Yes, it is a custom gateway that's currently in development. I'll have a further look at it as code-changes may have broken everything as it was working before. The last screenshot shows the Gateway::validate return values. Is there something you can see that's missing? StripeJs::success|return {"client_id":"1","amount":8.06,"currency":"AUD","status":"approved","reference_id":"ch_XXXXXXX","transaction_id":"ch_XXXXXXXXX","parent_transaction_id":null,"invoices":[{"id":"80","amount":"8.0645"}]} That's the log of the Success function if that's required as well
Tyson Posted July 6, 2015 Report Posted July 6, 2015 The log of the return values looks alright. Are the invoice amounts being returned arrays? array( ... 'invoices' => array( array( 'id' => 80, 'amount' => 8.0645, ) ) ); Michael 1
sktan Posted July 7, 2015 Author Report Posted July 7, 2015 The log of the return values looks alright. Are the invoice amounts being returned arrays? array( ... 'invoices' => array( array( 'id' => 80, 'amount' => 8.0645, ) ) ); Yes, it's being returned as an array.
Paul Posted July 7, 2015 Report Posted July 7, 2015 Just an update. This may be related to the issue described here - http://www.blesta.com/forums/index.php?/topic/4754-paypal-payments-applied-as-account-credit-then-to-oldest-invoice/ A fix is in the works for 3.5.1
sktan Posted July 8, 2015 Author Report Posted July 8, 2015 Just an update. This may be related to the issue described here - http://www.blesta.com/forums/index.php?/topic/4754-paypal-payments-applied-as-account-credit-then-to-oldest-invoice/ A fix is in the works for 3.5.1 Thanks! If they're related, it would really be a huge relief as I was really wondering what I did wrong as according to comparisons I made my code-changes shouldn't've changed anything that badly.
Paul Posted July 8, 2015 Report Posted July 8, 2015 Thanks! If they're related, it would really be a huge relief as I was really wondering what I did wrong as according to comparisons I made my code-changes shouldn't've changed anything that badly. I'm pretty sure it is. Please watch for the 3.5.1 release in the next week or so and see if it corrects the issue. If you create a manual invoice that has only 2 decimal precision, ie ($4.55) and it works correctly then you are most likely impacted by this bug. And, you'll have confirmed that your gateway is working correctly.
Tyson Posted July 8, 2015 Report Posted July 8, 2015 You could also update your gateway with a temporary fix such that the values you return as invoice amounts are rounded to two decimal places.
sktan Posted July 9, 2015 Author Report Posted July 9, 2015 You could also update your gateway with a temporary fix such that the values you return as invoice amounts are rounded to two decimal places. I'm pretty sure it is. Please watch for the 3.5.1 release in the next week or so and see if it corrects the issue. If you create a manual invoice that has only 2 decimal precision, ie ($4.55) and it works correctly then you are most likely impacted by this bug. And, you'll have confirmed that your gateway is working correctly. After testing with a clean $10 invoice and the payment showing up fine, it looks as though they're the same bug.
Recommended Posts