Escanor

[ruby kiln]

Hi there

[reef vapor]

Damn that was quick wow

Sorry I'm just quite surprised by the efficiency of this 😅

[ruby kiln]

Let's go one at a time:

1. If I create a setup intent, add a credit card payment method and the customer loses his credit card 2 hours after and declares it as lost to his bank to get a new one, is there a way for me to know of this via maybe a webhook or would I even see it when calling the retrieve endpoint of the said payment method?

No you won't know until an authorization is attempted again. Either another SetupIntent or a Charge attempt.

We are here to help and my team staffs 24/5 so someone should be around most of the time!

Sometimes we are slower to respond when things are busy

Anywho....

2. Upon retrieving a payment method (credit card), is there a way for me to know whether or not that credit card is still valid or if it was declared as stolen/lost?
   No not without performing an Authorization via SetupIntent or Charge

3. Upon retrieving a payment method (credit card), do I have to validation manually for the credit card expiration date or does Stripe handle this on its end and it would let me know of this?
   If you are using Elements or Checkout then we validate that it is an expiration in the future, then we rely on the issuer to respond with whether it was correct or not.

4. Is it only by trying to make a payment/charge on a credit_card that I can be made aware if it was declared as lost/stolen or anything else like this? Would I be able to achieve that upon retrieval of the credit card?
   Yep see above, Charge or SetupIntent

5. I saw that in Canada there is such a thing as pre-authorization for debit cards where there would be a very small charge on the account to then be refunded. Is there such a thing available for credit cards?
   No this isn't supported for credit cards.

You really should just be using a SetupIntent for that

6. In a scenario where there is a returning customer that we always charge his credit card without issues and we offer him our services during an urgency without charging him before but then when we try to charge him, it says that his credit card is not valid because it was declared as stolen. What can we do?
   You bring the customer back on-session and collect a new payment method from them to charge them!

But really, I just wouldn't do this.... if they are "returning" meaning they are on-session, I wouldn't let them go off-session without a successful Charge

Otherwise I wouldn't provision my product

[reef vapor]

@ruby kiln Sorry for the delay in my answer, had a phone call that came up!

The issue is that it's always off-session in our case. For a bit more clarification, we're just transitioning to Stripe for our customer and the payments are done manually on the dashboard I think. The customers don't interact with our website at all, it's just employees of the client's company that manually charge the customers for the services through the dashboard. So we're always just creating setup intents to save cards for future usage for now and later on they can charge the customer.

Some other questions:

7. I saw that you said that pre-authorization is not possible, but what about perhaps trying to charge the customer for like 0.50$ and refunding him right away only once?

8. Is it good practice to perhaps detach the customer's payment method if it's been added for more than 3 months so that the employee has to re-add the payment method through a setup intent to trigger the authorization once again?

9. From what I understand, considering our client's situation, what do you mean when you say you "wouldn't provision my product"? Do you mean that you'd never offer the product/service without charging the customer upfront?

10. In such situations, would it be interesting to "hold" the payment up to 7 days before delivering the service to the customer? From my understanding, it's kind of like staying at a hotel and doing so would make sure you have the necessary amount to pay and it's freezed in your account until charged after delivering the service? What's the benefice of doing this instead of just charging the customer upfront?

Sorry for all the questions 😱

[errant otter]

Hi there 👋 I'm jumping in as my teammate needs to step away soon. Please bear with me a moment while I read through your questions.

[reef vapor]

Oh sure! No worries, thanks a lot for the amazing help 🙏

[errant otter]

7. I saw that you said that pre-authorization is not possible, but what about perhaps trying to charge the customer for like 0.50$ and refunding him right away only once?
   I don't think this is a good approach due to Refunds not refunding the processing fee:
   https://support.stripe.com/questions/understanding-fees-for-refunded-payments

Would placing a hold, and then capturing the funds later (within 7 days) work for your flow? It looks like that is available via the dashboard as well:
https://stripe.com/docs/payments/place-a-hold-on-a-payment-method

8. Is it good practice to perhaps detach the customer's payment method if it's been added for more than 3 months so that the employee has to re-add the payment method through a setup intent to trigger the authorization once again?
   I haven't heard guidance along these lines before, I think this would be a choice for you to make based on what is best for the flow you're trying to accomplish.

9. From what I understand, considering our client's situation, what do you mean when you say you "wouldn't provision my product"? Do you mean that you'd never offer the product/service without charging the customer upfront?
   The advice seems to suggest that you wouldn't want to provision access to your product/service before you've confirmed you were successfully able to receive payment, but please let me know if it seems I'm missing context.

10. In such situations, would it be interesting to "hold" the payment up to 7 days before delivering the service to the customer? From my understanding, it's kind of like staying at a hotel and doing so would make sure you have the necessary amount to pay and it's freezed in your account until charged after delivering the service? What's the benefice of doing this instead of just charging the customer upfront?
    It's mostly about building a flow that meets your business requirements. Both approaches charge the customer.

[reef vapor]

@errant otter (not sure if I need to tag you?) Why would one want to place a hold on a payment method and capture the funds later instead of just capturing them now? How would that benefit us? Is it perhaps easier to "cancel" the charge?

[errant otter]

If it doesn't help your business flow then you may not need to use it. When you place the hold the payment authorization is performed at that point. Then the funds are reserved until the payment is canceled or captured.

[reef vapor]

And would there be processing fees were there be a need for cancellation?

Because the difference with charging now would be that if there's an issue, we wouldn't be able to "cancel" but only refund for which processing fees will already have been issued right?

[errant otter]

You'll want to speak with our Support team regarding the specifics on fees, we are only loosely aware of them but are not familiar with the details of fee structures (we primarily focus on helping answer questions about our API or how to integrate using it).
https://support.stripe.com/?contact=true

[reef vapor]

Gotcha, this cleared 99% of my doubts 🙂

Gotta say though, the system you guys have in place for answering questions in absolutely incredible... I've never had such an awesome live support, it would always be some kind of hold for 15 mins to get a very unclear and uncertain answer 😅

Thank you very, very much for all the help @errant otter 🙏

Have an awesome day!!

[errant otter]

Always happy to help where we can! Thank you so much for the kinds words, I'll be sure to relay them back to my team.

Hope you have a great day as well!