The data being provided to stripe for transactions related to customers does not appear to be accurate.
We started using Invoice Ninja (hosted) at the start of this year and we’re just doing some auditing of records.
In that process we have found that Invoice Ninja is providing Stripe with what I would consider is ‘bad’ data (or maybe just ‘useless’ data).
The “Customer Description” is being populated with Invoice numbers; however, if it is a recurring invoice, it populates with the original invoice number.
The “Customer ID” is being populated with a unique ID for the customer; however, the ID is only consistent throughout a calendar month. So in January “Customer A” has an ID of “cus_7g4sGyYzuqgwZq”; however, in February that same customer has an ID of “cus_7g5W1wfTjvCLj3”.
This makes the Stripe data impossible to reconcile without significant manual work.
Can you please provide Stripe with the proper data during a transaction?
“Customer Description” = Name of Customer
“Customer ID” = a unique ID that is the same (always) for that customer?
The customer id is determined by Stripe, I don’t believe we can set it.
We’ve made some improvements in this area in our next release. You can patch your release by copying over the latest version of this file: https://github.com/invoiceninja/invoiceninja/blob/develop/resources/views/payments/payment.blade.php
OK … I’ll give the manual patch a try and let you know how it goes.
The customer ID was just a 2nd option.
BTW … there is a Stripe button on the client page (in InvoiceNinja) that links directly to stripe for the client, but it only displays the current month’s data.
I’m wondering why Stripe is changing this so often. It kinda makes it useless.
Could there be a way for IN to ‘get’ that ID and store it within IN and then use that ID in the future?
(Just wondering if that would solve the ‘change each month’ issue).
Are you using token billing, if the customer re-pays with the same card I think it should link to the same customer.
Yes, using Token billing with ‘opt-out’ selected.
And the payments are using the same card (from what they have told me).
Do you know if they’re clicking ‘Use card on file’ or are they re-entering their card details?
They are using the CC on file.
And it’s also happening on the recurring (which would also be the CC on file).
Also, I’m using the latest release (18.104.22.168).
And I’ve also now applied the patch you referenced above.
I’ve also noticed a couple payments where the name field (in stripe) is listing “No name provided”.
These entries were manually entered.
So it really looks like there’s a problem getting the proper data to stripe for ALL transactions for the Customer Name field.
Thanks for the info, we’ll look into it for the next release.
I thought using the recurring invoice number for the Stripe profile was strange also. I could not figure out why a second recurring invoice from the same customer was billed too another recurring profile. After digging around in the database I concluded the Stripe customer ID was assigned to the customer and not the invoice.
Is the Invoice Ninja Customer ID unique? If so then shouldn’t the Stripe profile description really be the Invoice Ninja Customer ID?
We are still thinking this process through on our side. For now we have a script that audits and fixes all the Stripe profile descriptions daily.
We use Omnipay (https://github.com/thephpleague/omnipay-stripe) which has made some improvements related to this. We plan to upgrade to their latest driver in an upcoming release.
BTW … this isn’t a stripe issue. We used Freshbooks with stripe for a couple years and didn’t have any problems with this sort of thing. But I’m guessing that they have the resources to have a dedicated coder just for their stripe interface. I don’t see any bugs in that issue tracker, so I’m hoping this is just a simple implementation issue.
Please let me know if I can help with the process in any way (testing, etc.).
Has there been any development on this (on upgrading the Omnipay files)?
In our next version we’ve added the email address.