#luxterful_docs

1 messages · Page 1 of 1 (latest)

fossil hazelBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1349033459074469940

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

visual plaza
#

We need:

  • iDEAL
  • the deffered flow to tackle the user which itterates credit cards (to also be able to rate limit him and also to be able to use captcha, if it does not stop him right away)
  • to use subscriptions to handle recurring paments
  • to fix the 0.00€ issue for google pay

Notes why we only have one solution:

  • deffered flow offers a way to create a subscription right away but unfortunately iDEAL and Bancontact does not work with it
  • we cannot just use payment intents since they are use to charge the user right away and trials just dont work with it

Solution:
I think the only option now is to use the deferred flow and switch between setup and payment depending on the selected plan of the user.
The plan with trial is preselected, so i will initialize elements with mode "setup".
If a user will select the plan without trial, i will update elements to use mode "payment”.
When the user click purchase we will confirm the intent (either payment of setup depending on the plan) on the successful redirect in my backend, we will create subscriptions like: For setup intents we can just use the payment method right after the successful redirect to create the sub. For payment intents we can setup "store payment method for later" and then create a subscription which starts after the first period.

Issues remaining:
First invoice for payment intents wont be linked to the subscription, but is that an issue?
For the payment intents we need to create a subscription which starts after the first period.

solar otter
#

Hello, that sounds like a good solution, though I am not sure I fully understand the issues you are describing. Using a SetupIntent for trials and a PaymentIntent w/ setup_future_usage: 'off_session' if there is a payment upfront is definitely the right way.
Unfortunately we don't support showing anything other than $0 for Google Pay setups at the moment. I am not that familiar with GPay, but if you know that it can show something else I can put in a feature request.

#

Are you mostly confirming that setup vs payment intents is the right way to go for each situation and whether there was a way to change what the google pay sheet shows?

visual plaza
#

The issue is that the first invoice is not linked to the subscription and thats why i thought: "creating a payment intent which does not charge the user but is only for storing the payment method" could be the best solution so that we dont have to change too much

#

Unfortunately we don't support showing anything other than $0 for Google Pay setups at the moment.
i know, thats why i'd like to use payment intents... so its more like a trick...

solar otter
#

Oh I see now. So what you can do here is actually create the Subscription and pass the ID of its first invoice's payment intent and use subscription mode

visual plaza
#

and use subscription mode
what do you mean with this?

solar otter
visual plaza
#

unfortunately subscription mode does not work with iDEAL 😦 so its not an option

solar otter
#

Can you tell me what is happening overall on your webpage at this point? The user is setting up a subscription, potentially with a trial, and if they are paying you want to let them pay with iDEAL but just for the first subscription cycle?

visual plaza
#

We have the plan selection and stripe elements on the same page. The user can select a plan with trial and a plan without trial. We want to setup the subscription so that the automatic handling is in place but with setup intents we have the google pay issue

#

my idea was to use payment intents but "kind of missuse" them to show the user the amount it will cost but dont charge the user but only store the payment method and use it to create the subcription with it which then will charge the user

#

this would be the best variant

#

And i just tried GPay with payment intents and it shows me the amount. If i use "setup_future_usage: 'off_session'" i can store the payment method but i am wondering if the user still gets charged by this payment intent and if i can avoid the charge

solar otter
#

Yes the user will always get charged in that scenario. Unfortunately there isn't a workaround here. You can either accurrately show that you are charging $0 now, or accurrately show that you are charging some real amount. Like I said I can put in a feature request for the future, though unfortunately I can't guaruntee that that would get picked up, for now the best way would be to use our officially supported flows

visual plaza
#

ok. i am wondering what the field capture_method on the payment intent does then?

solar otter
#

That defines whether the authorization and capture parts of a payment are coupled. That said, you should not place holds and cancel them as a workaround there. I don't think banks like holds being placed unless you actually intend to capture the funds

visual plaza
#

gotcha

#

what about confirmation_method, off_session, use_stripe_sdk

how do those fields change the payment intent. Just want to understand how those things work

solar otter
#

Confirmation method can let you require that intents be confirmed server-side
https://docs.stripe.com/api/payment_intents/object#payment_intent_object-confirmation_method
off_session is a parameter on the create and update calls that lets you indicate that the customer is not currently around to perform actions like 3DS. It is used to indicate things like recurring charges or one off charges while they aren't around.
use_stripe_sdk is for certain aspects of handling a next action like 3DS, I forget what flows it is used in but it is pretty rare to have to use it. If you are looking at a guide that has it I can take a closer look at that

The PaymentIntent object | Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

fossil hazelBOT
visual plaza
#

@solar otter thx for your help and details!

#

If my idea with "missuse payment intents to only store the payment methode" wont work as i intended it to... then i need to use payment intents and let it charge the use but also create a subscription with the payment method i got from the payment intent via setup_future_usage: 'off_session'. How can i manage it so that the user wont be charged again when i create the subscription, so how can i "skip" the first period of the subscription since it was already paid via my payment intent?

solar otter
#

If my idea with "missuse payment intents to only store the payment methode" wont work as i intended it to
This will not work. To save a PM with a payment intent, you need to fully confirm it, which will inherently charge the customer.
The best way would be to use the subscription's actual first payment intent. If you want to do a one-off intent that only charges for the first month, you can try making the subscription with a 100% off one-time coupon, but you'll run into the same payment method type issues on the next recurring payment unfortunately.

visual plaza
#

This will not work. To save a PM with a payment intent, you need to fully confirm it, which will inherently charge the customer.

i think you misunderstood. Yes thats something i accept now. So my idea is:

use the payment intent and also charge the customer with it. With setup_future_usage: 'off_session' i can store it with the customer and use the payment method to create a new subscription right away but let the subscription "skip" the first period

#

so set the start date to the future?

frozen thorn
#

Hi! I'm jumping in for my colleague here. What exactly are you trying to accomplish (besides trying to not show a 0.00 GPay charge)?

visual plaza
#

to understand it you need to read the full thread

frozen thorn
#

Can you summarize for me?

visual plaza
#

In our payment flow we need:

  • iDEAL
  • the deffered flow to tackle the user which itterates credit cards (to also be able to rate limit him and also to be able to use captcha, if it does not stop him right away)
  • to use subscriptions to handle recurring paments
  • to fix the 0.00€ issue for google pay

Notes why we only have one solution:

  • deffered flow with mode "subscription" DOES NOT WORK WITH iDEAL

Solution:

  • the only option is see is to use the deferred flow and switch between setup and payment depending on the selected plan of the user.
    • The plan with trial is preselected, so i will initialize elements with mode "setup".
    • If a user will select the plan without trial, i will update elements to use mode "payment”.
  • When the user click purchase we will confirm the intent (either payment of setup depending on the plan) on the successful redirect in my backend, we will create subscriptions like:
    • For setup intents we can just use the payment method right after the successful redirect to create the subscription.
    • For payment intents we can use setup_future_usage: 'off_session'

---> my question is now regarding the last step!
With setup_future_usage: 'off_session' i can store it with the customer and use the payment method to create a new subscription right away but let the subscription "skip" the first period
... so set the start date to the future?

frozen thorn
#

Awesome, thank you.

First: iDEAL is single use so you'll never be able to use it for recurring billing, but SEPA can be (and I believe they're very similar in how they work).

Second: I don't understand what "iterates credit cards" means, can you explain that?

Third: That's what Subscriptions are for, so that's great. 🙂

Fourth: There's no way to fix that issue with Google Pay, as it's a Google issue not a Stripe issue - and a very common one at that: https://www.google.com/search?q=google+pay+0+dollar+charge+site%3Awww.reddit.com

visual plaza
#

First: iDEAL is single use so you'll never be able to use it for recurring billing, but SEPA can be (and I believe they're very similar in how they work).

Sorry but this is wrong.

with latestPaymentAttempt.payment_method_details we can get the SEPA and create the subscription from that

#

please dont comment my solution. please only answer my last question!

frozen thorn
#

It's actually not wrong, but ok.

What is your last question? How to create a trial?

visual plaza
#

It's actually not wrong, but ok.
For the user its still iDEAL which is used to pay for a subscription! Internally we use SEPA, yes

#

What is your last question? How to create a trial?
are you kidding?

#

---> my question is now regarding the last step!
With setup_future_usage: 'off_session' i can store it with the customer and use the payment method to create a new subscription right away but let the subscription "skip" the first period
... so set the start date to the future?

frozen thorn
visual plaza
#

Ahaaa! Thank you!

#

This was helpful

#

have a nice day

frozen thorn
#

You too!

visual plaza
#

One last question. Your colleague mentioned a way to attach the invoice of my payment intent to the subscription which i will create from the stored payment method. How do i do this?

frozen thorn
#

You mean you'd create an Invoice, and then associate that Invoice with a Subscription?

visual plaza
#

yes

#

your colleague said: So what you can do here is actually create the Subscription and pass the ID of its first invoice's payment intent

frozen thorn
#

I've never heard of that, and from what I can tell it doesn't seem to be the case. Let me see if I can check with them.

visual plaza
#

ok

fossil hazelBOT
rocky osprey
#

fyi i'm taking over for timebox - i'm also not familiar with a way to do this so we're waiting to hear back still, but i will let you know when i have an update

visual plaza
#

allright, thx

#

I would like to raise a feature request:
iDEAL works as a payment method for subscriptions created via checkout sessions.

please also make it work for the deffered flow

fossil hazelBOT
fossil hazelBOT
rocky osprey
#

ok sorry about the delay @visual plaza, we just heard back from our colleague and now we're realizing we're not 100% sure what your objective is with this:

attach the invoice of my payment intent to the subscription which i will create from the stored payment method.
is your end goal just to have a subscription paid automatically with a stored payment method?