#brel_api

1 messages ¡ Page 1 of 1 (latest)

cyan ginkgoBOT
#

👋 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/1391748590656819210

📝 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.

swift wind
#

hi there!

pale frigate
#

hi

swift wind
#

how are you accepting payments? Checkout Session, Payment Element, something else?

pale frigate
#

I am using a custom implementation

#

on the frontend I am using Payment elements

swift wind
#

so you use PaymentIntents + Payment Element?

pale frigate
#

I dont use payment intents

#

I save customer card

#

and then do the subscribtion create call from my backend

#

So customer card is saved on the frontend

#

And sent directly on Stripe

#

from Payment Elements

swift wind
#

got it, but a Subscription does contain a PaymentIntent, so it's the same.

#

the Payment Element doesn't support promo code. so that's something that you'll need to build yourself.

pale frigate
#

yes

#

that's why I asked how can I validate it?

#

Is there a way I can validate the promo code?

#

Like an api or something that returns the validity when promo code is passed

cyan ginkgoBOT
swift wind
#

got it. but no we don't have this.

#

that's something that you'll need to build on your end.

#

or use Checkout Session to accept payments, which does support promotion code.

pale frigate
#

What is checkout session. Is handled by Stripe. Can I keep the custom integration I have or I need to redirect customer to another screen?

quaint sun
#

@pale frigate since you're using subscriptions there are a couple of things that I would suggest you'd do to enhance and improve your current integration. I will also explain how you can see the validity of a coupon without using Checkout Sessions(which is the best way to do it)

pale frigate
#

Thank you

quaint sun
pale frigate
#

But promotion_code

#

not coupon

quaint sun
#

based on the returned invoice you can clearly see whether the promotion code was applied or not

pale frigate
#

I am currently making the customer add a card

#

And then I create the sbscribtion from my backend

quaint sun
#

you shouldn't do that

#

you should follow the steps in the guide I sent you

pale frigate
#

What is the problem with that process?

#

I have been using it in prodution without problems

quaint sun
#

otherwise your customers might have to go through SCA twice

quaint sun
#

but since your customer is on_session when you create the subscription it's better to have them validate directly the subscription payment since the mandate would be created accordingly

#

so for disputes it's less risky because you have the evidence that they initiated the subscription

pale frigate
#

So, I am good with the actual implementation?

#

Sorry, I did not understand

#

IS it ok to just show the upcomming invoice?

#

Or should I change the flow?

#

I don't undersatnd what are hte implication with that, My customer has a customer_id. I create payment methods with his unique id

#

and I also create subscribtion with his ID only

#

That will fetch his payment methods

#

I've seen that the major part of the apps have this 2-step process. When they first save the card and then pay for subscribtion

#

Isn't my flow the same?

quaint sun
quaint sun
quaint sun
#

basically having to refund or deal with disputes

pale frigate
#

Got it, but even if I show that to the customer I think is better to let them know exactly what they will be charged. Correct?

quaint sun
#

yes you can

#

but you need to be extra thorough with the details you pass to the create preview. Everything that you pass to that preview you should pass to the subscription afterwards

pale frigate
#

Yes, got it. I am just concerned on the security now

#

Since you are saying my implementation is not correct

quaint sun
#

it's not a security issue

#

it's more of a way to protect your business from potential disputes

#

the customer could claim that they saved their payment method on your website but they didn't ask you to start a subscription for them

#

so they contact their issuing bank and they would open a dispute

pale frigate
#

Ah ok. But in either case, even if I implement differently, the merchant has the possibility to charge that from Stripe

quaint sun
#

your flow isn't wrong per se but it isn't the recommended way

quaint sun
pale frigate
#

I mean that technically from Stripe is possible

quaint sun
#

yes technically it's doable

pale frigate
#

For a card to be charged without permission

quaint sun
#

yes

#

but you need to optimize your auth rate and reduce disputes/refunds

#

so we don't recommend that flow

pale frigate
#

So, normally should'nt Stripe prevent creating a subscribtion directly by passing payment_method_id

#

If this is not recommended

quaint sun
#

we are an ever-growing company and our recommendations evolve, but we also need to have backwards compatibility, otherwise we would break the integration of so many merchants. we might get to a day where we create a breaking change version and remove this flow, same as when we deprecated sources and tokens which were valid as a way to create a subscription or payment in general

#

another example is Charges objects. Today Charges are still part of the API but we don't recommend using Charges to make payments

pale frigate
#

Thank you for the explanation