#vilesa - paymentintent

1 messages · Page 1 of 1 (latest)

topaz rivet
#

Hi there!

#

What do you mean "this will create a new payment method each time on stripe"?

#

How did you create all these payment methods in your screenshot?

fickle belfry
#

hello
As you can see on the screenshot, after each payment stripe will automatically attach a new payment method to the customer, all representing the same Apple Pay card

topaz rivet
#

Can you share two of the PaymentMethod IDs? pm_xxx

fickle belfry
topaz rivet
fickle belfry
#

yes, but at the time the user selects their card in apple pay, I have no way to know if that card was already added into stripe or not, so how do I know if I need to pass the param setup_future_usage=off_session ?

topaz rivet
#

The way it works in general:

  • The first time you create the PaymentIntent, you set setup_future_usage=off_session
  • Then the next time the customer want to pay, you directly create a PaymentIntent while setting the payment_method and confirm:true
    However, we don't recommend that with Apple Pay, see this doc: https://stripe.com/docs/apple-pay?platform=web#recurring-payments

For repeat purchases that aren’t related to a subscription, Stripe recommends that you create single-use tokens. Your customer must authenticate with the Apple Pay payment sheet each time—attempting to reuse payment information for a non-subscription payment can result in it being declined.

fickle belfry
#

yes, so what is recommended for apple pay?

topaz rivet
#

I guess the main solution is to not save the card (so not use setup_future_usage=off_session), and every time go though the Apple Pay flow. Unless it's for recurring payments and in that case you could use a subscription.

fickle belfry
#

yes but if I need to charge the card offline later for some reason, then I won't be able to do it?

topaz rivet
#

yes but if I need to charge the card offline later for some reason, then I won't be able to do it?
True, but like the documentation said, this is not really supported with Apple pay: "attempting to reuse payment information for a non-subscription payment can result in it being declined"

fickle belfry
#

I see! thank you!

#

same question for bancontact:

#

I use setup_future_usage=off_session, because I want the "generated_sepa_debit" payment method to be attached to the customer

but a new one is attach each time, how can we prevent this?

topaz rivet
#

I think I already answered this:

The way it works in general:

  • The first time you create the PaymentIntent, you set setup_future_usage=off_session, and it create a new Payment Method
  • The next time the customer want to pay, you directly create a PaymentIntent while setting the payment_method to the existing Payment Method and confirm:true
fickle belfry
#

that's not really my question

#

I want to allow my user to pay by bancontact, and to save the payment method (the generated_sepa_debit from the bancontact) in case I need to do some offline payments after

#

however if I use setup_future_usage=off_session
then I will have many duplicated sepa_debit payment methods

topaz rivet
#

however if I use setup_future_usage=off_session then I will have many duplicated sepa_debit payment methods
But why? I think there is a miss-understanding. You should create a PaymentMethod only once (with setup_future_usage=off_session). And then you can keep reusing the same PaymentMethod for the following payments.

fickle belfry
#

what do you mean by "You should create a PaymentMethod only once"

#

I am not creating the PM, I am creating the PI
then stripes creates the PM

topaz rivet
#

Let me try to re-explain this:

  • The first time the customer pays, you create the PaymentIntent with setup_future_usage=off_session. You collect the payment information, and Stripe creates a Payment Method (pm_123) attached to the customer.
  • Next time you create a PaymentIntent, you use payment_method:pm_123 and confirm:true in your API call. This way Stripe won't create a new Payment Method, but reuse the one you provided.
fickle belfry
#

yes makes sense, but it's not really what I want
because for bancontact : the PM is "real time", although the generated sepa debit is debit, so not real time (5 days)

#

let me know if not clear and I can clarify

full cliff
#

Hi there 👋 I'm jumping in as my teammate needed to step away. Please bear with me a moment while I catch up on context.

#

I'm seeing that you're looking to work with Bancontact, but that you have a concern over having duplicated Sepa DD payment methods, could you elaborate on that?

fickle belfry
#

hi, sure:

my customers pay with Bancontact

but I need to be able to charge them sometimes offline. So for that, I need to have a PM. So when creating the PI, I put setup_future_usage=off_session so that a sepa_debit PM is generated.

But now, my customers have dozens of sepa_debit PM on stripe because a different one is generated for each payment

full cliff
#

Okay, and what is your desired outcome?

fickle belfry
#

that stripes generates a sepa_debit once for a given bancontact PM

full cliff
#

We don't do any automatic deduplication. There are a couple approaches that you can look into though. If the Customer already has an existing Sepa PM, then you could avoid using setup_future_usage. Alternatively, you could use webhooks to listen for the creation of new Payment Methods, review the fingerprint for the PMs for the Customer, and delete any duplicates that are created.
https://stripe.com/docs/api/payment_methods/object#payment_method_object-sepa_debit-fingerprint

Stripe API reference – The PaymentMethod object – curl

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

fickle belfry
#

understood, thank you!

full cliff
#

Any time!