New Member
Posts: 23
Registered: ‎07-24-2015

Stripe API Upgrades

Is there a way to be notified when it is ok to upgrade my stripe api? 

 

I upgraded it a few months ago and it worked fine, however I upgraded to a new version yesterday and it caused error messages for subscriptions. I was able to downgrade and fix the issue. Just wondering if there is a way to monitor and be notified if the upgrades are ok to do.

 

Thanks,

Chris

Ubiquiti Employee
Posts: 4,170
Registered: ‎12-10-2015
Kudos: 1479
Solutions: 315

Re: Stripe API Upgrades

These breaking changes generated by Stripe are very unfortunate. We will do our best to adapt to them but we won't be able to monitor these changes and notify users in advance.

Can you please provide us with the info about the version you upgraded to?
New Member
Posts: 23
Registered: ‎07-24-2015

Re: Stripe API Upgrades

We are currently running on api version 5/21/18. This works fine, the new version is 7/27/18 and is the one that caused the issue.

Ubiquiti Employee
Posts: 4,170
Registered: ‎12-10-2015
Kudos: 1479
Solutions: 315

Re: Stripe API Upgrades

Thanks, we will look into it.
New Member
Posts: 12
Registered: ‎11-17-2017
Kudos: 5

Re: Stripe API Upgrades

How do we downgrade the Stripe API to 5/21/18 to get subscriptions working?

 

Thanks,

Dan

New Member
Posts: 23
Registered: ‎07-24-2015

Re: Stripe API Upgrades

It must be done on stripe's website under developer section. Unfortunately I believe you can only downgrade within a few days after upgrading. You may want to contact stripe if you are unable to.

New Member
Posts: 12
Registered: ‎11-17-2017
Kudos: 5

Re: Stripe API Upgrades

Thanks for the reply. I can't find where to change the API version on the stripe website under developers. We just signed up yesterday so maybe we don't get a choice.

 

stripe_fail.jpg

 

Thank you,

Dan

 

New Member
Posts: 12
Registered: ‎11-17-2017
Kudos: 5

Re: Stripe API Upgrades

Nevermind, it's on the developers link. I was looking in the API Keys just under developers. There is no way to downgrade. Calling Stripe to see how painful it is to downgrade. 

 

Thanks for the help.

Dan

 

Emerging Member
Posts: 80
Registered: ‎11-19-2009
Kudos: 38
Solutions: 1

Re: Stripe API Upgrades

I just went through exactly the same thing.  I signed up 2 days ago and they defaulted my API to 2018-07-27.  I opened a support chat, and after a bit of back and forth going through the typical level 1 diagnosis, I managed to articulate my issue and they said they needed to escalate the case and needed to move the chat to email to included another team member (I read that as escalation to level 2). They were very helpful and polite.

 

After ~24+ hours and a couple of email exchanges with them saying "they'll see if it's possible..." they were able to revert my API to the previous version 2018-05-21 which now works fine.

 

Rich

Ubiquiti Employee
Posts: 4,170
Registered: ‎12-10-2015
Kudos: 1479
Solutions: 315

Re: Stripe API Upgrades

Ok, we will also make UCRM compatible with the newest Stripe API version soon.
Highlighted
New Member
Posts: 44
Registered: ‎10-07-2015
Kudos: 36

Re: Stripe API Upgrades

[ Edited ]

@UBNT-Ondra what changed here?



We had tested everything with Stripe on 2/15/19 and our QA said our UCRM/Stripe was tested and production ready in Sandbox mode before we put everything in live/production and started our lengthy migration.



UCRM Was up to date with the most current version at that time. (2/15/19)



We finished our data migration had our customers all update their payment info in the portal, confirm accounts, etc.



April 1, 2019 (April Fools Day I guess, wtf)



Our billing goes live with Stripe processing/UCRM Linked Subscriptions.



None of the callbacks made to UCRM were working.  Every single one shows 200 "OK" response code, but no JSON data on the response:



Very clever April fools joke, im not impressed and neither are my customers, my staff, or my developers. Shame on you guys!



https://billing.jb-wireless.net/online-payment/stripe-webhook/1



(Production Ready QA Tested 45 Days ago when we started migration)

Very First Successful Transaction in LIVE



10 Seconds after Midnight:



invoice.payment_succeeded
evt_1EKHTLFwR9qqYiK3RWvrv4oG
2019/04/01 00:10
 
JSON Request attached in request-0401201900000010.json
 
UCRM Response: <Null>
(Screenshot Attached)
 
This JSON request was on a Manual Invoice Payment
 
Linked Business Class Plus 4M $99.99 every 1 month Started Apr 1st, 2019 Provider Stripe
 
 
Invoice 001986 Unpaid Created : 1.4.2019 - Due : 15.4.2019

Label Price Quantity Qty Total
Business Class up to 4Mpbs Apr 1st, 2019 – Apr 30th, 2019 99.99 1 99.99

Subtotal $99.99
Total price $99.99

Payment Did NOT Post to the account.

It does NOT Show Pending in the Client Zone.

LOOONG list of customers just like her. 

I look at the Release notes and you conviently released a new version of Stable Code on 3/28 That lists in the release notes:

Fixed
Fixed issues with Stripe subscription payments.
UI/UX improvements for google maps.
Fixed crashing receipt template in some cases of payments created via API.
Factory reset not working, doing no changes to the data.
Lets Encrypt TLSv1.0 removed, TLSv1.3 added.
Fix for possible issues with ticketing import from some client email replies.
Fixed displaying rounding difference on invoices with no custom rounding.
Minor API fixes.
Minor fixes.
Convient pre April fools joke release.  Who's playing the Joke, Stripe or Ubiquiti?

Stripe made the breaking changes to their API on 2/28:
2019-02-19
MajorStatement descriptor behaviors for card payments created via /v1/charges have changed. See our statement descriptor guide for details.
Instead of using the platform’s statement descriptor, charges created with on_behalf_of or destination will now use the descriptor of the connected account.
The full statement descriptor for a card payment may no longer be provided at charge creation. Dynamic descriptors provided at charge time will now be prefixed by the descriptor prefix set in the dashboard or via the new settings[card_payments][statement_descriptor_prefix]parameter in the Accounts API.
If an account has no statement_descriptor set, the account’s business or legal name will be used as statement descriptor.
Statement descriptors may no longer contain *, ', and ".













MajorMany properties on the Account API object have been reworked.
The legal_entity property on the Account API resource has been replaced with individual, company, and business_type.
The verification hash has been replaced with a requirements hash.
The verification[fields_needed] array has been replaced with three arrays to better represent when info is required: requirements[eventually_due], requirements[currently_due], and requirements[past_due].
verification[due_by] has been renamed to requirements[current_deadline].
The disabled_reason enum value of fields_needed has been renamed to requirements.past_due.
Properties on the Account API object that configure behavior within Stripe have been moved into the new settings hash.
The payout_schedule, payout_statement_descriptor and debit_negative_balances fields have been moved to settings[payouts] and renamed to schedule, statement_descriptor and debit_negative_balances.
The statement_descriptor field has been moved to settings[payments][statement_descriptor].
The decline_charge_on fields have been moved to settings[card_payments] and renamed to decline_on.
The business_logo, business_logo_large and business_primary_color fields have been moved to settings[branding] and renamed to icon, logo and primary_color. The icon field additionally requires the uploaded image file to be square.
The display_name and timezone fields have been moved to settings[dashboard].
business_name, business_url, product_description, support_address, support_email, support_phone and support_url have been moved to the business_profile subhash.
The legal_entity[verification][document] property (now located at individual[verification] and at verification in the Person API object) has been changed to a hash, containing front and back properties to support uploading both sides of documents.
The keys property on Account creation has been removed. Platforms should now authenticate as their connected accounts with their own key via the Stripe-Account header.
The requested_capabilities property is now required on creation for accounts in the US.


We subsequently backed up the database and upgraded to the latest code about Noon today.



Now we've got quite the mess and I've got hundreds of subscription payments to put in that the UCRM endpont accepted with 200 OK on the JSON Response so I cannot re-send the "Successful" webhooks as I would be able to have done if they had failed with any 4xx code.



I can manually fix the JSON of each one with a search/replace nomenclature, can I just go in with POSTMAN and post these corrected JSON's or is there an easier more mainstream metthod of correcting this?



Shame on Stripe for making breaking non backwards changes without updating the API version 



Shame on UBNT for it taking 30 days to update a breaking change to the API on the preferred processor.



We want IP Pay integration, they don't make breaking changes to their API like this.  They have strict policies against it.



I ADD payment subscriptions with ACH on IP PAY through their native interface and paste in custom webhook code to post the payment, can you please provide a generic webhook code for posting a payment such as this through the API.



We're interested in co-developing a module for IP Pay ACH if there are any other ISP's willing to split the cost.  I've got a developer in Manila that quoted $1,500 to write this.  



Guess I'll write it up on GIT, this isn't Stripe's first breaking change to their API and I'm sure it won't be their last.



https://community.ubnt.com/t5/UCRM/Stripe-API-Upgrades/m-p/2447843/highlight/true#M10694



Give Kudo's and PM me if you're interested in co-sponsoring the IP Pay Module

Update:
This appears to be working in 2-15-1 verision:

 

https://community.ubnt.com/t5/UCRM/New-UCRM-version-2-15-1-released/m-p/2738014#M14796

 

But how to fix what was sent to UCRM before the upgrade?

 

Also now UBNT is returning response codes but Stripe still doesn't recognize them as Failed API Calls because they're getting "200 OK" on the response with the error:

 

Status
200 Success (1 try)
Retry history
[2019/04/02 18:58 to https://billing.jb-wireless.net/online-payment/stripe-webhook/1]: (200) OK
Request
{
"id": "evt_1EKvYmFwR9qqYiK3cJmMsgV7",
"object": "event",
"api_version": "2018-09-06",
"created": 1554245908,
"data": {
"object": {
"id": "ch_1EKvYlFwR9qqYiK3BEtZlEzE",
"object": "charge",
"amount": 3999,
"amount_refunded": 0,
"application": null,
"application_fee": null,
"application_fee_amount": null,
"balance_transaction": "txn_1EKvYmFwR9qqYiK3h6zgt7fE",
"billing_details": {
"address": {
"city": null,
"country": null,
"line1": null,

See all 129 lines
Response
Payment with Stripe Charge ID "ch_1EKvYlFwR9qqYiK3BEtZlEzE" does not belong to UCRM, ignoring.

New Member
Posts: 44
Registered: ‎10-07-2015
Kudos: 36

Re: Stripe API Upgrades

Events of "balance.available" type are not handled by UCRM.

https://billing.jb-wireless.net/online-payment/stripe-webhook/1
200
invoice.payment_succeeded
evt_1EKsTTFwR9qqYiK3CyKZrdTP
2019/04/02 15:40
Request to your webhook
{
"id": "evt_1EKsTTFwR9qqYiK3CyKZrdTP",
"object": "event",
"api_version": "2018-09-06",
"created": 1554234047,
"data": {
"object": {
"id": "in_1EKsTTFwR9qqYiK3QSHttaVr",
"object": "invoice",
"amount_due": 0,

See all 121 lines
Response
Events of "invoice.payment_succeeded" type are not handled by UCRM.

Veteran Member
Posts: 4,739
Registered: ‎05-19-2009
Kudos: 902
Solutions: 27

Re: Stripe API Upgrades

IPpay already is integrated with UCRM and has been working perfectly for us

 

what issue are you having with ippay?

New Member
Posts: 44
Registered: ‎10-07-2015
Kudos: 36

Re: Stripe API Upgrades

Before Upgrade:

 

charge.succeeded
2019/04/02 13:54
Request to your webhook
 
{
 
"object": "event",
 
"api_version": "2018-09-06",
 
"created": 1554227659,
 
"data": {
 
"object": {
 
"object": "charge",
 
"amount": 6999,
 
See all 129 lines
Response
 
After Upgrade:

charge.succeeded
evt_1EKs4TFwR9qqYiK3qYNA8cBG
2019/04/02 15:14
Request to your webhook
{
"id": "evt_1EKs4TFwR9qqYiK3qYNA8cBG",
"object": "event",
"api_version": "2018-09-06",
"created": 1554232497,
"data": {
"object": {
"id": "ch_1EKs4RFwR9qqYiK3S7nMUBvU",
"object": "charge",
"amount": 100,

See all 129 lines
Response
Payment with Stripe Charge ID "ch_1EKs4RFwR9qqYiK3S7nMUBvU" does not belong to UCRM, ignoring.

 
New Member
Posts: 44
Registered: ‎10-07-2015
Kudos: 36

Re: Stripe API Upgrades

95% of our customers pay by ACH and IP Pay ACH Subscriptions apparently aren't a thing yet?

Veteran Member
Posts: 4,739
Registered: ‎05-19-2009
Kudos: 902
Solutions: 27

Re: Stripe API Upgrades

oh your issue is with stripe

 

 

for now I would make a backup of UCRM and roll back to the working version of UCRM

 

 

I have seen many complaints about stripe across google its a hard one to get working

 

I'm sure the UCRM team will have some type of hotfix

 

but the UCRM team is in the EU they don't seem to start work until about 3am EST

New Member
Posts: 44
Registered: ‎10-07-2015
Kudos: 36

Re: Stripe API Upgrades

@900mhzdude 

 

Thanks for the 3AM Tip, guess I'm going to be up for awhile waiting on someone to look at this.

 

Seems the issue is that UBNT isn't parsing the API Version date that Stripe is sending.

 

The webhook wasn't working on the previous version anymore even though it was working just fine for a mock run done in QA of 2/1 Billing Cycle done on 2/15 with a small sample of test data in sandbox mode.

 

I have the backup from right before the upgrade today and a backup from right now.

 

About to try restoring the data in to the latest UCRM Beta version in a separate QA VM to see if it's something that is fixed but not in the stable release yet.

 

Is your ISP running the Stable or Beta code?

Veteran Member
Posts: 4,739
Registered: ‎05-19-2009
Kudos: 902
Solutions: 27

Re: Stripe API Upgrades

are you running 2.15.1 stable?

 

 

ACH not a big thing for us its cheaper and better for them to do auto bill pay with their bank 

that auto mails payments for there bills

Veteran Member
Posts: 4,739
Registered: ‎05-19-2009
Kudos: 902
Solutions: 27

Re: Stripe API Upgrades

we are on 2.15.0 stable

 

 

make sure to DO NOT go to beta1 MAKE SURE to install beta2 or later if going to the beta branch