#gkiokan-sepa
worn umbra
@chilly orbit I have to run soon but I can have a look. Can you show me an example like a pi_123 I can look at?
worn umbra
PaymentIntent id pi_123. You mentioned "the card element" but maybe you are mixing up multiple concepts?
chilly orbit
I didn't check that, gimme one sec to see if I can get it on the production code
I am talking about that SEPA payment thing
pm_1LBqCNHa5WPIKK5ICkaO1YMW
worn umbra
okay that's the PaymentElement. And that works with a PaymentIntent id pi_123 or SetupIntent id seti_123
worn umbra
this is the logs for the API request that created that SetupIntent
you/your code is explicitly enabling SEPA Debit
chilly orbit
Thought it will auto generated from the backend settings
When I leave the fields empty, will it take the selected payment methods automatically from the stripe settings?
worn umbra
Yes and no. Even if it worked, it doesn't matter if you explicitly write code to enable it
But SetupIntent specifically does not yet support automatic payment methods
only PaymentIntents do. So when you take an immediate payment
SetupIntents are used to collect payment method details for future payments
chilly orbit
How does google get into the list? I just saw that on the production but not on the development / test version
I see. I will disable it then directly for now.
Well there are not that much payment methods that collects and charge the customer asap
worn umbra
GooglePay and ApplePay are associated with card specifically
But again if you use PaymentElement and SetupIntents, the settings in the Dashboard don't really matter
worn umbra
Of course!
curious why you use SetupIntent in the first place though
you seem to use Laravel Cashier so I assume you have a recurring revenue business
chilly orbit
Yea subscription based tiers made on a laravel backend. However I has build the frontend in vue, not that it matters but somehow I didn't got elements correctly working the way we wanted. So I sticked to the latest solution I could get working.
worn umbra
ack
The better integration flow is
1/ Create a Subscription with payment_behaviour: 'default_incomplete'
2/ Client-side, confirm the SetupIntent referenced in pending_setup_intent if you don't take a payment upfront
chilly orbit
I see. I made it the other way around. However the customer should pay when he chooses a tier so it's fine. Even it is not the best UX but a good way to get paid for the service we provide for them.
Perfect. sepa is now disabled.
worn umbra
yah that's even worse if you accept a payment upfront by the way
you should ~never do a SetupIntent followed up by an immediate payment
chilly orbit
why?
worn umbra
because SetupIntents were designed explicitly for the purpose of collecting payment method details for future payments
If you take a payment upfront you want
1/ Create a Subscription with payment_behaviour: 'default_incomplete'
2/ Client-side, confirm the PaymentIntent associated with the first invoice
This does one payment with one confirmation. For example it avoids having to do 3DS twice and decreases the risk of a decline
chilly orbit
I save the paymentMethod on the customer object and use it also for the next upgrades and quantity changes (quantity per applied employees)
There is something that I need to check next week. Is it possible to say charge the customer 14 days after he has subscribed?
worn umbra
my example will save the PaymentMethod for future payments too
and it depends what you mean by that, why specifically 14 days? Is it a trial period?
chilly orbit
Nah goverment rules in germany.
worn umbra
not sure what that could mean
chilly orbit
A customer can cancel a digital product within 14 days and if he do so we must send his money back.
Currently we charge the customer immediately after he chooses something. But to prevent the money send back thing it would be optimal if we could tell stripe to charge the customer 14 days after he subscribed
worn umbra
yeah that is not a thing unless you put them on a trial period until that date
chilly orbit
We are already using Trial period on a free tier. So they register, get assigned to a free tier for 30 days. When they upgrade we kill the trial and charge them. Currently.
worn umbra
I don't see how it's different from starting their subscription after 30 days of trial and still deferring the payment by 14 more days
feels like they already tried the product in your trial
But if they upgrade to a different price, I would still give them a new trial of 14 days
chilly orbit
feels like they already tried the product in your trial
Thats the Idea behind it
worn umbra
that way you defer the payment automatically and things just work
chilly orbit
I see
worn umbra
But there isn't a way today to say "this is active now, but charge in 14 days". I don't think we'd build something like this anytime soon
chilly orbit
billing_cycle_anchor I thought this param would be an timestamp in future. But the docs say only now or unchanged.
So the additional trial may be worth a look
worn umbra
yeah you can't change the billing cycle on an existing subscription
new trial_end is likely your best bet in that case
and then after 14 days they get charged for the next full month
but feels like a lot of people will abuse this so I'd recommend monitoring and only doing this for customers in that country
chilly orbit
Yea true. Thats something we need to monitoring and see how it goes. Even the payment is a one time process it took quite a bit time to figure out different scenarios. Let's see how it goes.
I will have a look into that paymentIntents stuff you wrote on top. However you was about to run or something. I won't steal your time 🙂 Thanks for the quick help. Have a nice day mate.
worn umbra
all good I'm glad I was able to clarify a few things