#Nepho-coupon
torpid jewel
Hello. What exactly is the issue? This all sounds normal
Like, what part is unexpected or what are you trying to prevent
tulip panther
Actually the issue comes from somewhere else 😓
I thought that the subscription wasn't created but the 1-time promotion code was consumed, but in fact the subscription IS created (when it shouldn't be because I haven't used any payment method anywhere).
Basically I have a yearly subscription in my stripe dashboard. I have a 100% off coupon that lasts 3 months.
The current behavior I'm observing is this:
- The user selects the yearly subscription, enters his 1-time promotion code
- The backend creates the subscription, sends the pending setup intent client secret back to the frontend:
seti_xxx_secret_yyy. - /!\ At this point, even though the user hasn't selected ANY payment method, the subscription is already live! Which shouldn't be possible.
- The frontend presents google pay form to the user so that he can pay. If he cancels this step, the subscription is considered active and the promotion code is (obviously) consumed.
Obviously this is wrong and something is not done properly.
Now if I check the dashboard after this process, I can see that my customer has the yearly subscription active (see screenshot 1). If I click on his invoice, it indicates that the user actually got 100% off for the whole year? (see screenshot 2)
Please tell me if my issue isn't clear, but there are actually 2 things very wrong here 😰
Also here are the details of the promotion code I used. As you can see it's 100%, but only for 3 months. So it shouldn't affect a yearly subscription for the complete first year.
covert ermine
Hey there 👋 what you're describing is all expected functionality, and if you want to avoid it then you'll need to redesign your processes. Please bear with me while I articulate why it's behaving this way.
Since the coupon that you're creating is a 100% discount, it will completely negate the charges on associated invoices. With the duration of that discount set to 3 months, it will discount any invoice generated within that 3-month period. This gets a little confusing when working with yearly subscriptions, because the first invoice bills for the first year, and since that invoice falls into the 3-month period of the coupon the 100% discount is applied to it. So the entire first year is discounted to free.
Since the first invoice is being discounted by 100% there is nothing to charge for on that invoice, and the subscription can be created, and go active, without payment information.
tulip panther
Okay, that all makes sense. Several questions:
- Why can the subscription go live if one year (or one month) from now there won't be any payment method to actually carry on with the subscription?
- How can I work with these sort of coupons then? If I have a yearly subscription and I want to provide my users with a 3-month 100% off coupon, how do I make it work?
Thanks in advance
covert ermine
-
Because sometimes it makes sense to not require a payment method up front, for instance there are scenarios where user's want to provide free access initially (through a trial or discount) and don't want to require payment details initially to avoid customer friction and drop-off. So we decided to give our users the flexibility to build flows that don't require payment details up front, or if they'd rather, they can designs that do collect payment details initially.
-
This depends on what you're actually trying to accomplish. Do you just want to charge your customers for 3-months less of the subscription? Or do you want to give them 3-months free, then bill them for the remainder of the year?
tulip panther
- OK, that makes sense! Is there no way to actually force the libraries to collect a payment method before activating the subscription though?
- I want my customers to be billed yearly after the trial period ends (which is 7 days in my case), but in this specific case with the 100% off for three months, I'd like them to pay:
• 0% the first three 1-month periods, then 100% every month if they take a monthly subscription
• 0% the first 3-month period, then 100% every 3 months if they take a 3-month period subscription
• 50% the first semester, then 100% the next if they take a 6-month period subscription
• 25% the first year, then 100% the next if they take a 12-month period subscription
I hope this is clear enough!
Again, thanks for the very detailed answers, they help me a lot!
covert ermine
The libraries won't require a payment method when a subscriptions first invoice is zero dollar, but you can add logic to accomplish something very similar. When a subscription tries to bill there are a series of fields that it looks in to find a payment method. First default_payment_method then default_source from the subscription object, and if those are both null then it will start looking at the customer record, particularly invoice_settings.default_payment_method then default_source. So when you're creating the subscription you can check the customer record that you're using to ensure there are fallback payment methods on the customer record, and raise an error (instead of creating the subscription) if there isn't.
Building those subscriptions will take some work since our subscriptions can only bill weekly, monthly, or yearly, we don't have the concept of 3-month or 6-month periods.
tulip panther
Regarding your last point, I managed to create subscriptions that are billed every 3-month or 6-month periods. So I'm not sure I understand correctly
covert ermine
Wow, not sure how I missed that. That'll actually make your scenarios much easier. You'll basically need to create 3 coupons.
- One for a 100% discount for 3-months (to be used with your 1 and 3 month periods)
- Another for a 50% discount, with a duration of less than 6 months (for use with your 6-month period)
- A final one for 25% discount, with a duration less than a year (for use with the annual plan)
You'll then need to add a little bit of logic to on your end to know which one to apply, based on the period of the subscription being created.
tulip panther
OK, well that's a bummer but at least it can be done!
Regarding the first point (having an obligatory payment method), can I use presentGooglePay to add a payment method? I'm a bit lost regarding the google pay integration. Because if the subscription requires payment, then I can select a credit card using presentGooglePay and the client_secret seti_xxx_secret_yyy associated to the pending setup intent.
But if the subscription doesn't require a payment method then the subscription starts right away and presentGooglePay is completely optional and I don't even think going to the end of the process would actually add a payment method to the stripe's customer?
Thanks in advance
covert ermine
I'm pretty sure you still can, but you wouldn't rely on the subscription to be the trigger for it. Instead your flow would probably look something like:
- Check if there is an existing payment method that you can use
- Collect one if not: https://stripe.com/docs/payments/save-and-reuse?platform=android&ui=payment-sheet
- Create the subscription
tulip panther
Thank you, I'll take a look 👍
tulip panther
I'm trying to implement what you've told me but I fail to understand how I can add a new payment options using Google Pay... 😰
It seems like within the react-native library, Google Pay is only used for payment/setup intents.
Can I create a setup intent that would retrieve a customer's payment method using presentGooglePay?
If so, how do I create such a setup intent on the backend? I'm so confused ahah
Also... It seems like I'm actually legally obliged to use Google's billing system for Android applications.
I think if I only use Google Pay to get the user's payment method, but then everything is handled by Stripe, my application will be refused? It's incredibly hard to find answers to these kind of questions online...
trail saddle
I am not as familiar with RN, are you running in to an error when passing some setup intent details to presentGooglePay?
You should be able to create that setup intent server side like any other setup intent, no special config required. https://stripe.com/docs/api/setup_intents/create
Do you have any docs or anything that you can send me on that last quesiton on being refused for using Stripe?
tulip panther
Hello and thanks for your answers. OK for the setup intent.
Regarding the rest of my rant 😓, I don't have much unfortunately.
I've developed an android application using react-native and stripe.
Everything worked perfectly, and I was using <CardField /> (the preferred method with the react-native library: https://github.com/stripe/stripe-react-native#usage-example).
I then submitted the application to Google but it was refused, Google claiming that I needed to use Google Play's billing system.
I then asked about integrating Google Pay into my application so that I can comply on this channel and some kind people helped me.
Now I have Google Pay somewhat working, but it doesn't change the fact that Stripe is the one doing all the subscription payments/invoices. So I'm afraid integrating Google Pay into the application isn't changing anything to my problem.
Do you have answers regarding Google's billing policies with Stripe? Thanks in advance, and sorry for the rant, it's just that I've changed the payments/subscriptions/billing system like 3 times at this point and it's still wrong or not compliant... It's annoying 😰
trail saddle
Thanks for the info, I am not familiar with this subscription but will look in to it and consult my colleagues.
tulip panther
Thanks! I hope you can shed some light on the situation. No matter what solution I lean towards it doesn't seem to change the core issue that Google doesn't want me to let Stripe handle subscriptions
tulip panther
@trail saddle: did you manage to get any info at all?
trail saddle
As best I can tell, it is true that you need to use Google's billing system for in app purchases of subscriptions like that. But I am unfortunately not finding anything very authoritative here. I would reach out to Google's support for clarification on this
Our support may also have better policy knowledge on this. I am more familiar with the coding aspect of these things so I haven't been able to find much on the policy https://support.stripe.com/?contact=true
tulip panther
OK, thank you. By any chance, do you know where I can contact Google's support? I haven't found any way to contact them so far 🥲
plain granite
Hello. Taking over for Pompey here. That I cannot advise on actually as I am not sure
tulip panther
Hi! OK. I found a form to contact them I'll give it a try. So just to summarize, my app had a full payment pipeline using Stripe only (no Google Pay at all), and my application got refused. Now I'm not really sure what the issue was.
lapis solstice
There are strict rules on what types of apps can accept payments via Google Pay though. It's not every app since most apps have to use Google's system + IAP
it's the same as Apple. Whether you can use Stripe in your application depends on what you're selling exactly. The idea is that if you sell physical products like groceries or a gym membership or ticket concerts you can use Apple Pay in your application which means you can also use Stripe in your application. On the other hand, if you sell a digital subscription or extra levels in your game for example then you can't use Stripe and have to use Apple's solution instead called IAP.
And as far as I know Google has the same rules
tulip panther
Thanks for the answer
That's what I understood as well, but I've found a lot of applications that use Stripe, Paypal, Mangopay, you name it, for premium content/subscriptions, and they seem to have been approved? The most well-known being Spotify. But there are smaller applications that target the same business as mine that provide ways to get a subscription directly inside the application without using google pay. 🤷♂️
lapis solstice
Spotify is special and has a direct relationship with Google though, like Netflix, Amazon, etc. Unfortunately this is all decided on Google and Apple's sides, we have no control over this
tulip panther
OK, I see. I've contacted Google's support hoping to get a precise answer but I'm afraid that I'll have to manage every subscriptions using their "Play billing"... That sucks a lot considering the time I've spent integrating Stripe 😰
I wish this was better documented, both on Google side and Stripe's side. I guess my case is a bit special since it's subscriptions, if it was one-time-purchases I'd probably be able to use Google Pay that's already integrated in Stripe but for subscriptions I don't think I can.
Thanks for the great support either way