Skip to main content
Question

Flutter Cross Platform Project: Web Payments

  • 7 March 2023
  • 5 replies
  • 808 views

Using Flutter, I’ve built out subscriptions for Android & iOS using the RevenueCat Flutter SDK. I was a bit confused as to why there wasn’t support for the Web Platform - so now I am having trouble wrapping my head around how to integrate payments on the web platform. 

 

I have read through all of the documentation regarding integrating web payments with Stripe, and i have the Stripe integration set up - however, I feel that hasn’t given me a good path to move forward on. 

 

Essentially - these are the methods I use to get subscriptions working in my app: 

 

// Should I fetch products from RevenueCat or Stripe on the web?
Future<List<Product>> fetchProducts();

// Should I grab customer information from RevenueCat or Stripe on the web?
Future<bool> identify({required User user});

// I assume this should be handled by Stripe
Future<bool> purchase({required Product product});

 

The flow of it all is quite difficult for me to understand. For the mobile apps - revenuecat Is the primary channel for subscription information.

For the web, is this different? Do I use one or the other - or is it a combination of both RevenueCat and Stripe? 

To integrate RevenueCat with Stripe, you need to complete the purchase through Stripe on your side then you forward the subscription token to RevenueCat.

For the web, is this different? Do I use one or the other - or is it a combination of both RevenueCat and Stripe? 

Yes. With the mobile apps the RevenueCat SDK initiates the transactions with the stores then validates and saves the purchase. With web (Stripe) you’re responsible for completing the purchase, then you can use the RevenueCat REST API to send the purchase into RevenueCat.

I would look into the Stripe SDK and/or Stripe Checkout to help out with this. It really is/should be a completely different flow than the checkout in your mobile app. For example you’ll need a way for the customer to enter their credit card details and a place for them to manage/cancel their subscription - things that are handled out-of-the-box by Apple/Google.

@ryan thank you for this. So I thought that with the Stripe/RevenueCat Integration, Stripe would automatically send purchase events to RevenueCat, but that doesn’t seem to be the case? So the flow looks like:

1. User purchases a product through Stripe
2. I send the app user id that made the purchase and the receipt token to revenue cat
3. RevenueCat links those two together, and all further updates with that receipt will alter the users subscription as needed? 

Yup! That’s exactly the flow. There’s a few things holding things back from being fully auto-magic, and one is the lack of RC App User ID in the Stripe webhooks as you noted.

Here’s a sample of a setup may help: https://github.com/RevenueCat-Samples/stripe-no-website-example

@ryan Thanks! Can you please give me final clarification on the following scenario:

  1. User Signs up in the mobile app with user id: user_123
  2. RevenueCat.identify() is called with user id: user_123
  3. User logs into the web app and purchases a subscription
  4. Since this is the users first time logging into the web app, a new Stripe customer is created for that user. For reference, their Stripe Customer ID is: stripe_123
  5. The purchase is successful and I POST to the RevenueCat Receipt Endpoint with app_user_id:user_123 and I pass in the appropriate stripe fetch token. 

So after Step 5, will RevenueCat associate the subscription attached to Stripe Customer Id: stripe_123 with the RevenueCat user user_123? Meaning that any renewals/expirations associated with the user stripe_123 will be handled on user_123

That’s correct, the customer ID that Stripe generates is ignored by RevenueCat, it’s only concerned with the subscription. The subscription will be kept up-to-date automatically through the RC <> Stripe integration and will be associated with the App User ID that you sent through the POST API call - in your example `user_123`. 

Reply


Terms & ConditionsCookie settings