#alexanderg-payment-method

1 messages · Page 1 of 1 (latest)

alpine merlin
#

HI 👋 the biggest advantage is that then the payment method can be reused for other payments for that customer. If it's not attached to a customer then it's single-use.

bold canopy
#

Is there a downside of attaching a payment method to customer?

#

... the use case we have is basically a shopping cart style business where users enter the card before checkout.

alpine merlin
#

None that I'm aware of.

bold canopy
#

Basically if I use setup_future_usage while creating payment intent then I will be able to use it in the future as it attaches the payment method to customer?

alpine merlin
bold canopy
#

What would be the best way for us to attach payment method to customer, ideally during create payment intent Stripe API call (auth only, not capture).

alpine merlin
#

Apologies, I was off earlier, setup_future_usage is the parameter to use for this. Out of curiosity though, do you plan to capture the payment later, or are you trying to just do the auth?

bold canopy
#

So the scenario we have is as follows: 1. auth only, then 2.a. capture (if within 7 days), or 2.b. reauth and capture (if > 7 days - auto cancelled). We need the reuse of payment method for step 2.b. Would setup_future_usage be the best option here if we want to reuse the payment method from step 1?

alpine merlin
#

Yes it would be.

bold canopy
#

off_session is fine? the customer is not present, its done by our back office staff

orchid panther
#

Yes, off_session is what you will want to use to indicate they aren't present when the funds are captured

bold canopy
#

@orchid panther I asked to toby already but is there any downside to using this to your knowledge?

#

ie using setup_future_usage vs not using it

orchid panther
#

Not that I can think of either. Can you clarify what the "reauth" part of step 2b is here?

bold canopy
#

It means that we initially auth the card (eg for 500$) then wait to capture. Sometimes capture takes place after 7 days, so the original auth expires. In this case we need to auth and capture the card again (for 500$) which is not done by customer but by our back office staff. So the hope is if we do use setup_future_usage during the initial auth, then we can use the same payment method and all the other info to do auth and capture after 7 days. In which case we would get a new payment intent (the original one being auto cancelled).

#

The key for us to be able, in case reauth and capture fails, to try it again with the same payment intent, ie work with FAILED state, which I assume can only be done if payment method is attached to customer.

#

My understanding is that setup_future_usage is what attaches payment method to customer to allow the above

#

... to clarify we do reauth and capture past 7 days already but if it fails we cannot just 'try' again with the same payment intent. This is why I thought setup_future_usage would help

orchid panther
#

Yes, that is definitely the way you want to use those parameters then

#

Set up future usage and on site for the first auth and then off site for the subsequent ones

#

Also if you haven't already, I would write in to support about longer auth windows. They are only available for certain industries (as determined by card issuers) but our support may be able to help you if that is applicable to you

bold canopy
#

About longer Stripe auth window, ie beyond 7 days?

willow hollow
#

Hey @bold canopy
following up on this thread about auth beyond 7 days, yeah that's what Pompey meant.
On our end it shows there's no way to extend it beyond 7 days but if you reach out to support and see if there are any betas, private features or anything as such just to reconfirm.

bold canopy
#

Sounds good 👍

#

And one more question, once payment intent is in Failed state (and given it is assigned to customer) which API method do I use to retry it?

willow hollow
#

looking into it
apologies for the delay
juggling between multiple threads

orchid panther
#

Apologies I dropped off this thread for a bit. What do you mean by a failed state here?

bold canopy
#

Not after initial hold window. For example we try a payment method auth/capture and it failed with insufficient fund. The client fixed the issue and in one hour we want to try again on the same (failed) payment intent (not create a new payment intent or payment method).

#

So basically we want auth and capture on the same intent without changing any info, just a retry after a few hours

pine plover
#

So unfortunately it's not possible to use the same payment method on that payment intent. You can use the same payment intent but would just have to switch the payment method

bold canopy
#

I thought if the payment method is attached to customer I can use it again?

radiant birch
#

If it is attached yes it can still work

#

But is it attached?

bold canopy
#

It would be as the initial call will be with setup_future_usage (please let me know if it is incorrect)

#

My question is what API method can I use to again retry the same payment intent (with same info as initially including same payment method)

#

... the one that failed at first

radiant birch
#

You can't, that's the thing, it's impossible. If the previous attempt failed, card details get dropped, we don't "save" a PaymentMethod that failed. So you need to re-ask for card details again

bold canopy
#

I was told in this thread that if the payment method is attached to customer I can, is it not what you listed above.

#

Also I have the payment method and other info from the original call handy (in my DB)

radiant birch
bold canopy
#

I have the payment method id , eg
pm_1KJO4JI7FT03hK3lIcMqb0sU

#

no card info

#

Basically again - I have payment intent that failed and I want it to succeed by trying again. How can I do it using the Stripe API and without the card details (#, expiry, cvc...) but with all the details from the original call. e.g....

#

{
"amount": 100,
"applicationFee": 10,
"authorizeAndCapture": true,
"description": "abc",
"idempotencyKey": "3344571239871234",
"metadata": {},
"metadataMap": {},
"paymentMethodId": "pm_card_chargeDeclinedExpiredCard",
"paymentType": "P2P_VEHICLE_PAYMENT",
"paymentsPartyDestinationId": 278668,
"paymentsPartyId": 278669,
"platform": "DIGITAL_RETAIL",
"receiptEmail": "agelberg@cargurus.com",
"statementDescriptorSuffix": "suff"
}

radiant birch
#

But you have to understand that you can't with the flow you are using. It's doable but highly discouraged, don't try that

#

I can explain but if I explain, then you'll just ignore what I said and do it anyway, which will be bad for your business

#

the first time you accept a payment, you collect card details online, the payment synchronously fails, we don't attach/save the PaymentMethod, since it failed and we expect you to retry in the future by asking the customer for updated card details

bold canopy
#

So is it bad to have payment method attached to customer and redp it?

radiant birch
#

that is the canonical flow you should use

bold canopy
#

If we no longer have the access to customer card and the payment intent fails, what can our back office staff do to retry the same card?

#

It looks like a pretty standard feature - e.g., customer had his limit exceed and fixed it and we want to try again the card.

radiant birch
#

I'm sorry, you seem to be mixing things up but I'm not succeeding at explaining why

#

If John doe pays $10 on Monday and it works, you get pm_123 attached to customer cus_123 and you can re-use that card in the future.

#

If they attempt to pay on your website for the first time on Monday, and it fails, nothing is saved. Nothing should be saved. Your staff shouldn't just retry a payment 3 days later without telling your customer in any way. They tried to pay, you told them it failed, that's the end of the payment

bold canopy
#

John Doe only does the auth of $10 (not capture) but our staff does the capture (when customer gets the goods), this is payment intent #1. Now, if capture is beyond 7 days it cannot be done. So backoffice staff does auth/capture of $10 (new payment intent #2). Now if auth/capture fails we would like to try it again after an hour or so (with the same payment intent #2, instead of creating a new one #3 with another auth/capture).

radiant birch
#

Yeah I don't get that sentence at all I'm sorry. What is failing? What's past 7 days?
If the auth succeeds it should attach the PM

bold canopy
#

Yes, auth succeeds and can attach the PM. After 7 days pi #1 gets auto cancelled (no capture takes place), this is why we need pi #2

#

These are the steps

#
  1. auth by client succeeds, payment intent #1
#
  1. payment intent #1 is cancelled (expires) capture cannot take place
#
  1. new payment intent #2 auth/capture is created by office staff but fails (e.g., no funds on card)
#
  1. we need to retry (auth/capture) payment intent #2, how can we do it without involving the client and his card.
radiant birch
#

But that doesn't add up to what you said earlier. Step #4 happens after the card has already been authorized successfully (step #1) and automatically attached to the customer

bold canopy
#

between #1 and #4 the card can run out of funds

radiant birch
#

that doesn't matter at all to the flow at hand

bold canopy
#

it does

#

I need to auth/capture a payment at step 4 which failed at step 3

radiant birch
#

again, doesn't matter

#

card was successful at step 1

#

Let's pause. Now that I understand your flow, can you give me an example request id that fails?

bold canopy
#

ok, so what should I do if at step 3 the card fails. yes, one sec...

radiant birch
#

You just retry again to confirm the same PI id with the original pm_123 that worked at step 1

bold canopy
#

Yes, I am looking for Stripe API which would do the confirm

radiant birch
bold canopy
#

Great, thank you! 👍

radiant birch
#

sorry for all the hassle. It looked like you wanted to do this where the first PI is the one failing and the card never gets "attached"

bold canopy
#

np, I have to admit our scenario is not straightforward 👍 .

#

Thanks for the help