We have a subscription-based, multi-platform product that’s available on Web, Android, and iOS.
Last week we set up Google Play and Apple Store integration with RC for our product and it’s finally working. We just started doing Stripe integration for our Web users, and it seems to be a lot more complicated and confusing than we expected. We feel that Strip integration is a 3rd-class citizen of RC, since there are only one vague doc, and a 2 year old sample code and a lot of required manual work.
Here are our thoughts and questions.
1) Any use of SDK for Stripe at all?!
When we first evaluated RC, we thought the Purchases SDK of RC would give us a hand on all platforms. (See the first paragraph below)
However, it seems like the Client Side SDK of RC should be completely discarded on Web/Stripe, as it cannot do basic tasks like
getPurchaserInfo (Source) even when we pass the strip_xxx Public API Key and app_user_id to the
setup() method of SDK. It throws
So, the question is, is it really like this (basically RC doesn’t have any SDK for Stripe) or we are missing anything?
2) Working with Async Webhook/Events of Stripe
The doc for Stripe integration says:
(and by the way the link doesn’t work. It should be /receipts not #receipts)
2.1) “You can” or “You must”?
Is there any other way (than using the
/receipts endpoint) that we can make RC+Stripe work?
2.2) Why can’t this be a webhook listener in RC?
We understand that some people might want their own custom server-side work, but if the whole purpose of such server-side endpoint is to transform the purchaseData and send it to the
/receipts endpoint of RC, why wouldn’t RC take it directly?
2.3) What should be the order of the events here?
We are on RC Pro plan to get the most out of RC. One of the features there is Stripe Server Notifications. In its doc it says:
And the webhook for Server Notifications should be listening to
customer.subscription.updated event of Stripe. (and 2 other events.)
Now, putting all the pieces of this jigsaw puzzle together, it seems like order of the events should be:
- Customer purchases should be made through Stripe’s checkout.
- Stripe will fire
checkout.session.completedwhich per the example old code, we should just take and transform and send to RC.
- RC will also listen to the
customer.subscription.updatedevent via a webhook, but it fails if the receipt doesn’t exist.
Now, given all of these are async server-to-server calls (“2” goes through stripe→ours→RC servers, which is longer than “3” going through stripe→RC servers), how can we guarantee that “2” always happens before “3”? (or per the warning box, the event will fail on “3”.)
2.4) Any plan to update the docs?
It took us half a day of reading the doc and the sample code four times each plus going through half of the Stripe’s API docs to guess how the whole thing should be implemented for a simple “We just want the equivalent of App Store’s monthly subscription, on Web.” Any plan to make it easier for future developers who will pick RC?
3) In an ideal world...
Last but not least, as a suggestion, in an ideal world here is how things would be working.
- Instead of the
cordova_not_availableerror, the SDK (which takes the
strip_xxxPublic API Key and user ID) would make the necessary AJAX calls to the RC APIs (offering and subscribers) and it would return the
purchaserInfovalues in the SDK, seamlessly.
purchaseProductfunction of the SDK would create a checkout session (pop-up, or navigation with return-url), with that package/product ID. Payment link API could be an option, probably.
- There would be no required server-side code to process the
checkout.session.completedevent and notify RC of via receipts API. It would be just a stripe-webhook→RC-API integration on
checkout.session.completedevent, that would just take 2 minutes to copy and paste a link.
- And that would be it to get Stripe working in 5 minutes, instead of 2 days of reading and 2 days of implementation! And we would definitely be willing to pay 1.5% (instead of 1.2% of Pro) to get this done easier and faster. :)