New Member
Posts: 23
Registered: ‎08-01-2015
Kudos: 1
Solutions: 2
Accepted Solution

UCRM not correctly posting stripe subscription payment

Still having discrepancies with Stripe Subscriptions: (I'm in Sandbox mode & stripe test mode)

1) I set up a service for $250/mo

2) Set up a subscription payment on Stripe. Verified in both Stripe events & webhook for payment event that the $250 was charged successfully to the client.

3) No sign of payment showing up on UCRM (again, the webhook showed UCRM was successfully notified)

4) Added. a one-time payment via the stripe interface for $11. Again the webhook was executed successfully.

5) This time it showed up as a payment on UCRM

6) The "invoice hour" arrived, and a new invoice for $250 was created

7) It now shows a balance due of $239, but only the one-time payment... nothing from the subscription

 

Screen Shot 2019-03-06 at 8.38.11 PM.png
Screen Shot 2019-03-06 at 8.38.50 PM.png

Accepted Solutions
New Member
Posts: 23
Registered: ‎08-01-2015
Kudos: 1
Solutions: 2

Re: UCRM not correctly posting stripe subscription payment

The problem I had was a webhook that was sent by stripe, but never processed by UCRM. Since we had just reset the database, it is possible it was related to being the first webhook? After that webhook started arriving normally.

 

the beauty and complexity of a stripe subscription is that stripe dictates the payment cycle and notifies ucrm with webhooks. UCRM has its own invoicing cycle daily. If all is working they stay in sync with webhooks. If for some reason UCRM stops responding, clients will still be billed, and you will still be paid.  I have used stripe subscriptions via Moonclerk for years, and it works really well!

View solution in original post


All Replies
New Member
Posts: 20
Registered: ‎05-01-2018

Re: UCRM not correctly posting stripe subscription payment

What is the difference between a service and subscription in UCRM. And why can clients pay with debit/credit card if they have a subscription but they can’t if they just have a service?  Also with a subscription it only allows them to pay with a debit/credit card. With service it just takes what credit they have on there account. 

New Member
Posts: 23
Registered: ‎08-01-2015
Kudos: 1
Solutions: 2

Re: UCRM not correctly posting stripe subscription payment

The problem I had was a webhook that was sent by stripe, but never processed by UCRM. Since we had just reset the database, it is possible it was related to being the first webhook? After that webhook started arriving normally.

 

the beauty and complexity of a stripe subscription is that stripe dictates the payment cycle and notifies ucrm with webhooks. UCRM has its own invoicing cycle daily. If all is working they stay in sync with webhooks. If for some reason UCRM stops responding, clients will still be billed, and you will still be paid.  I have used stripe subscriptions via Moonclerk for years, and it works really well!

New Member
Posts: 23
Registered: ‎08-01-2015
Kudos: 1
Solutions: 2

Re: UCRM not correctly posting stripe subscription payment

Back to webhook errors....

 

I setup and paid a subscription on UCRM with a credit-card (sandbox mode). 

 

Stripe shows 200 success, with this in its log:

{

  "id": "evt_1EEO3zFlLMTkTyaTkYT3lDpM",

  "object": "event",

  "api_version": "2019-02-19",

  "created": 1552687179,

  "data": {

    "object": {

      "id": "in_1EEO3yFlLMTkTyaThryGFN6c",

      "object": "invoice",

      "amount_due": 25000,

      "amount_paid": 25000,

      "amount_remaining": 0,

      "application_fee": null,

      "attempt_count": 1,

      "attempted": true,

      "auto_advance": false,

      "billing": "charge_automatically",

      "billing_reason": "subscription_create",

      "charge": "ch_1EEO3yFlLMTkTyaTN7p22oFL",

      "created": 1552687178,

      "currency": "usd",

      "custom_fields": null,

      "customer": "cus_EhnfhcYajYHZMw",

      "date": 1552687178,

      "default_source": null,

      "description": null,

      "discount": null,

      "due_date": null,

      "ending_balance": 0,

      "finalized_at": 1552687178,

      "footer": null,

      "hosted_invoice_url": "https://pay.stripe.com/invoice/invst_PKDi7fgnFMEq1AxLhN9DFe5zjO",

      "invoice_pdf": "https://pay.stripe.com/invoice/invst_PKDi7fgnFMEq1AxLhN9DFe5zjO/pdf",

      "lines": {

        "object": "list",

        "data": [

          {

            "id": "sli_2ececc7bf8bbe2",

            "object": "line_item",

            "amount": 25000,

            "currency": "usd",

            "description": "1 × $250.00 / 1 month - client103 Testing (at $250.00 / month)",

            "discountable": true,

            "livemode": false,

            "metadata": {

            },

            "period": {

              "end": 1555365578,

              "start": 1552687178

            },

            "plan": {

              "id": "ucrm_stripe_p8_1552687152",

              "object": "plan",

              "active": true,

              "aggregate_usage": null,

              "amount": 25000,

              "billing_scheme": "per_unit",

              "created": 1552687176,

              "currency": "usd",

              "interval": "month",

              "interval_count": 1,

              "livemode": false,

              "metadata": {

                "paymentPlanId": "8",

                "clientId": "10"

              },

              "nickname": null,

              "product": "prod_EhnfNxo4GB1oVc",

              "tiers": null,

              "tiers_mode": null,

              "transform_usage": null,

              "trial_period_days": null,

              "usage_type": "licensed"

            },

            "proration": false,

            "quantity": 1,

            "subscription": "sub_Ehnf83xIma8S31",

            "subscription_item": "si_EhnfrDD7rcxacq",

            "type": "subscription"

          }

        ],

        "has_more": false,

        "total_count": 1,

        "url": "/v1/invoices/in_1EEO3yFlLMTkTyaThryGFN6c/lines"

      },

      "livemode": false,

      "metadata": {

      },

      "next_payment_attempt": null,

      "number": "44B9DCF-0001",

      "paid": true,

      "period_end": 1552687178,

      "period_start": 1552687178,

      "receipt_number": null,

      "starting_balance": 0,

      "statement_descriptor": null,

      "status": "paid",

      "status_transitions": {

        "finalized_at": 1552687178,

        "marked_uncollectible_at": null,

        "paid_at": 1552687178,

        "voided_at": null

      },

      "subscription": "sub_Ehnf83xIma8S31",

      "subtotal": 25000,

      "tax": null,

      "tax_percent": null,

      "total": 25000,

      "webhooks_delivered_at": null

    }

  },

  "livemode": false,

  "pending_webhooks": 1,

  "request": {

    "id": "req_8j9bIFu7etVSVg",

    "idempotency_key": null

  },

  "type": "invoice.payment_succeeded"

}

 

 

UCRM prod.log shows:

 

[2019-03-15 14:59:39] request.INFO: Matched route "stripe_webhook". {"route":"stripe_webhook","route_parameters":{"_controller":"AppBundle\\Controller\\ClientZone\\OnlinePaymentController::stripeWebhookAction","id":"1","_route":"stripe_webhook"},"request_uri":"https://ucrm.kizawireless.com/online-payment/stripe-webhook/1","method":"POST"} []

 

[2019-03-15 14:59:39] security.INFO: Populated the TokenStorage with an anonymous Token. [] []

 

[2019-03-15 14:59:40] app.ERROR: Payment with ID "ch_1EEO3yFlLMTkTyaTN7p22oFL" does not belong to UCRM, ignoring. [] []

Highlighted
Ubiquiti Employee
Posts: 4,034
Registered: ‎12-10-2015
Kudos: 1429
Solutions: 312

Re: UCRM not correctly posting stripe subscription payment

Thanks for the log @DennyBoll
Can you please provide steps you did to reproduce this issue? Did you use the guide for testing the Stripe in sandbox mode?
New Member
Posts: 23
Registered: ‎08-01-2015
Kudos: 1
Solutions: 2

Re: UCRM not correctly posting stripe subscription payment

1) added client

2) added UCRM service

3) paid for the subscription with Stripe dummy 4242 card

4) checked that I got 200 OK in stripe log

5) tail -f prod.log  shows the error

 

The webhook is setup per instructions (worked when I tested last week).  Sandbox mode.

 

As you can see, the token that stripe sent in the webhook was rejected by UCRM.

 

Denny

New Member
Posts: 23
Registered: ‎08-01-2015
Kudos: 1
Solutions: 2

Re: UCRM not correctly posting stripe subscription payment

Debugging again.  The key seems to be "Payment with ID xxx does not belong to UCRM".  What can cause that message in your code?

Ubiquiti Employee
Posts: 1,436
Registered: ‎03-21-2016
Kudos: 234
Solutions: 159

Re: UCRM not correctly posting stripe subscription payment

Hello @DennyBoll, most likely UCRM does not have customer ID from Stripe associated with a Client. We're not sure how this can happen as it never happened in our testing.

However, UCRM 2.15.1 will have even more verbose logging for this, plus there will be fallback matching based on subscription ID for subscription payments, so even if we don't have customer ID in database it could still be matched based on the subscription.

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

Re: UCRM not correctly posting stripe subscription payment

@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
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 monthStarted Apr 1st, 2019Provider 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, 201999.99199.99
 SubtotalTotal price
$99.99
$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