08-07-2018 09:08 AM
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.
08-08-2018 01:15 AM
Can you please provide us with the info about the version you upgraded to?
08-10-2018 11:49 AM
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.
08-10-2018 01:59 PM
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.
08-10-2018 02:33 PM
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.
08-11-2018 12:49 AM
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.
04-02-2019 05:42 PM - edited 04-02-2019 06:13 PM
@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!
(Production Ready QA Tested 45 Days ago when we started migration)
Very First Successful Transaction in LIVE
10 Seconds after Midnight:
JSON Request attached in request-0401201900000010.json
UCRM Response: <Null>
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
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 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.
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:
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.
Give Kudo's and PM me if you're interested in co-sponsoring the IP Pay Module
This appears to be working in 2-15-1 verision:
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:
200 Success (1 try)
[2019/04/02 18:58 to https://billing.jb-wireless.net/online-payment/stripe-webhook/1]: (200) OK
See all 129 lines
Payment with Stripe Charge ID "ch_1EKvYlFwR9qqYiK3BEtZlEzE" does not belong to UCRM, ignoring.
04-02-2019 06:17 PM
Events of "balance.available" type are not handled by UCRM.
Request to your webhook
See all 121 lines
Events of "invoice.payment_succeeded" type are not handled by UCRM.
04-02-2019 06:17 PM
IPpay already is integrated with UCRM and has been working perfectly for us
what issue are you having with ippay?
04-02-2019 06:21 PM
Request to your webhook
See all 129 lines
Payment with Stripe Charge ID "ch_1EKs4RFwR9qqYiK3S7nMUBvU" does not belong to UCRM, ignoring.
04-02-2019 06:25 PM
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
04-02-2019 06:37 PM
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?
04-02-2019 07:02 PM
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
04-02-2019 07:12 PM
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