kavish_best-practices | Stripe Developers | Page 1

shrewd sundialBOT Mar 24, 2025, 10:51 PM

#

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

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

kavish_best-practices, 2 hours ago, 5 messages

#

elder furnace Mar 24, 2025, 10:53 PM

#

I have been using setup intent and get setup intent succeeded as well but when actually creating an invoice and charging the user I get payment failed due to incorrect pin.
This tells us the user has been using fraudulent cards and we aren't able to verify this with setup intent

#

#

Could you help on what is going wrong with these payment?

slow lark Mar 24, 2025, 11:01 PM

#

hello! yes, if you want to charge $1 right off the bat then a payment intent would be the way to go. you'll want to pass setup_future_usage: "off_session" when creating the payment intent. how are you surfacing the payment intent to users? via the Payment Element?
https://docs.stripe.com/api/payment_intents/object#payment_intent_object-setup_future_usage

elder furnace Mar 24, 2025, 11:01 PM

#

No the 1$ would be ideally directly charged using the payment intent on the backend when the user attaches a payment method

#

But we would then want to refund it once the payment succeeds and that would increase the refund rate

slow lark Mar 24, 2025, 11:04 PM

#

you can do that, but when charging a payment intent offline there's always a chance that you'll need to bring the user back online for 3DS which would be a little redundant

#

we also confirm with the issuing bank that the card is valid when you go through the setup intent process, so i'm also curious why you're doing additional verification? it also feels redundant to me

elder furnace Mar 24, 2025, 11:05 PM

#

It is because the payments are failing after setup intent succeeds

#

I have provided the screenshots above

slow lark Mar 24, 2025, 11:06 PM

#

can you share an example payment intent?

elder furnace Mar 24, 2025, 11:06 PM

#

We are currently using setup intent

slow lark Mar 24, 2025, 11:06 PM

#

but you said the payment is failing, and that means that there should be a payment intent

elder furnace Mar 24, 2025, 11:06 PM

#

We do that using invoices

#

We add the amount and details to the invoice

slow lark Mar 24, 2025, 11:07 PM

#

yep! even invoices have a payment intent

#

https://dashboard.stripe.com/test/payments

#

if you click on one of these you should be able to snag a payment intent ID from the URL

elder furnace Mar 24, 2025, 11:07 PM

#

Let me get the example for you

#

We do this on the backend

📎 message.txt

#

We create the subscription as so

    paymentSettings := &stripe.SubscriptionPaymentSettingsParams{
        PaymentMethodTypes:       []*string{stripe.String(string(stripe.PaymentMethodTypeCard))},
        SaveDefaultPaymentMethod: stripe.String("on_subscription"),
    }

    // Create the subscription. Note we're expanding the Subscription's
    // latest invoice and that invoice's payment_intent
    // so we can pass it to the front end to confirm the payment
    subParams := &stripe.SubscriptionParams{
        Customer: stripe.String(customerId),
        Items: []*stripe.SubscriptionItemsParams{
            {
                // adds default price ID
                Price: stripe.String(os.Getenv("STRIPE_DEFAULT_SUBSCRIPTION_PRICE_ID")),
            },
        },
        PaymentSettings: paymentSettings,
        PaymentBehavior: stripe.String("default_incomplete"),
        BillingCycleAnchorConfig: &stripe.SubscriptionBillingCycleAnchorConfigParams{
            DayOfMonth: stripe.Int64(1),
            Hour:       stripe.Int64(7),
            Minute:     stripe.Int64(59),
            Second:     stripe.Int64(59),
        },
    }

slow lark Mar 24, 2025, 11:13 PM

#

are you not seeing the payment intents in the link i sent you? at this point it's more important that i have an example to look at rather than looking at your code

#

i also might be able to find it from a setup intent ID

elder furnace Mar 24, 2025, 11:13 PM

#

One of the setup intent ID is in the screenshot I provided

#

Let me get a payment id

slow lark Mar 24, 2025, 11:16 PM

#

it's not reliable for me to re-type the ID from a screenshot, text is always preferred

elder furnace Mar 24, 2025, 11:16 PM

#

pi_3Qtk5HLoz3M8FCeu1Td489ww

#

This is one of the payment intent ids

#

#

It failed due to the reason shown above

#

But the setup intent for the user had succeeded

#

The reason for the additional 1$ verification is because these payment failures when setup intents have succeeded

#

So is these something wrong with the verification on the setup intent or the way we are charging the user?

slow lark Mar 24, 2025, 11:33 PM

#

ok, it looks like you're using the billing portal which i am a little less familiar with than calling setup intents directly. gimme a bit to look into this

elder furnace Mar 24, 2025, 11:33 PM

#

Okay thank you!

slow lark Mar 24, 2025, 11:36 PM

#

one other quick question, is there a reason you're using invoices? normally you would want to use payment intents directly with confirm: true and off_session: true for something like this
https://docs.stripe.com/api/payment_intents/create

elder furnace Mar 24, 2025, 11:37 PM

#

Let me check this

#

We thought it is the easiest way to charge and customers can reason about it

#

But with this as well what can the reason for the payments failing be?

#

initially we were using subscription invoices but now we start billing the customer every 25$ accrued so for that we are create invoices tied to a customer directly.

#

We aren't going to be using invoices for the test charges of 1$

slow lark Mar 24, 2025, 11:42 PM

#

i'm still looking into the setup intent side of things. i'm noticing that the setup intents don't include this param, which is needed for charging off session:

usage: "off_session"
https://docs.stripe.com/api/setup_intents/create#create_setup_intent-usage

#

it's unclear to me if the billing portal supports this, so i need to look into that real quick

elder furnace Mar 24, 2025, 11:43 PM

#

Okay

#

But even without this param the intent still succeeded right?
Then the verification is complete right?

shrewd sundialBOT Mar 25, 2025, 12:01 AM

#

elder furnace Mar 25, 2025, 12:02 AM

#

Hi @serene magnet can you help with the above?

#

??

slow lark Mar 25, 2025, 12:12 AM

#

hey kavish! sorry for the delay - sam is taking over the thread and i'm in the process of handing things over to them

elder furnace Mar 25, 2025, 12:13 AM

#

Okay thank you!

serene magnet Mar 25, 2025, 12:16 AM

#

Hi! Just catching up! Will be getting back to you soon.

elder furnace Mar 25, 2025, 12:16 AM

#

Thank you!

#

The main question is if the setup intent is succeeding why are the payments failing due to invalid or fraud cards according to us

#

Is there an update? I don't want the thread to be closed

serene magnet Mar 25, 2025, 12:35 AM

#

Thanks for waiting! Doing $1 live test charges is not recommended as it can raise issues on the issuer end as card testing. This may lead to failed payments as issuers may decline it.

#

Can I understand your business case for this better? Does the subscription start as a trial which is why you are creating a setup intent?

elder furnace Mar 25, 2025, 12:37 AM

#

No there isn't a trial

#

We are a IaaS platform and when the user deploys their first instance we ask for payment method and attach it to the user

#

Simultaneously create the setup intent

#

And when the intent succeeds and payment method is attached we activate the user's subscription and provision their instance

#

But weh have run into a lot of these payment failures and suspect fraudulent activity so we want to do these 1$ test charges and activate their subscription only once it succeeds

#

Since the card isn't being properly validated with setup intent as shown in the screenshots I provided

#

It is a pay as you use model

serene magnet Mar 25, 2025, 12:41 AM

#

Are you doing a payment intent and setup intent all at once?

elder furnace Mar 25, 2025, 12:42 AM

#

No the setup intent is done when initially the payment method is attached

#

Payment intents are with the invoices which are when the user accrues 25$ in usage and we bill them using invoices

#

Or at the end of the billing cycle again using invoices

serene magnet Mar 25, 2025, 12:43 AM

#

Are you using Invoices by itself or using Stripe Billing?

elder furnace Mar 25, 2025, 12:43 AM

#

The setup intent succeeds but the payments fail

#

We are using invoices that are generated on the backend and attached to the customer

serene magnet Mar 25, 2025, 12:46 AM

#

Is my understanding below correct?

You get the customer to provide their payment method via the Customer Portal which goes through the setup intent
The setup intents succeed
Then you create an invoice to charge that payment method
Some of the invoices fail

elder furnace Mar 25, 2025, 12:47 AM

#

Yes

#

For some users it always fails

#

Which leads us to believe it is a fraudulent user

#

We use invoices itself for the 25$ usages and Stripe subscription invoices for others or normal billing at the end of month cycle

serene magnet Mar 25, 2025, 12:52 AM

#

Payments failing for some customers doesn't indicate that they're fraudulent. Card declines are a common occurrence in payments.

elder furnace Mar 25, 2025, 12:52 AM

#

#

What is the reason in this case?

#

The setup intent had succeeded for this

#

For such users they keep using our service and accrue the costs but don't make the payments when we charge the payment method

serene magnet Mar 25, 2025, 12:57 AM

#

Have you attempted to charge them again or asked for a difference payment method?

elder furnace Mar 25, 2025, 12:58 AM

#

We have charged again but it fails again
We haven't asked for a different payment method

#

But even with a different payment method my main question is if the setup intent succeeds is the card supposed to be completely valid based on Stripe verification?

#

Since any of these charges are made after the intent succeeds right so our goal is to not allow invalid cards itself

serene magnet Mar 25, 2025, 1:04 AM

#

A payment can fail for multiple reasons. A successful setup intent doesn't determine that all subsequent payments will be successful. Sometimes the customer may fail their auth, issuers may decline for their own reasons, etc.

elder furnace Mar 25, 2025, 1:05 AM

#

So for our use case what is the best practice to follow? How should we setup initial verification and what to do when these payments fail?

#

@slow lark mentioned to use off_session: true when doing these charges
Is that something that is the only difference or is it something we need to change drastically?

serene magnet Mar 25, 2025, 1:17 AM

#

Setting up a payment method via Setup Intent doesn't not guarantee that subsequent payments will succeed. If payments are failing you can retry it. If it keeps getting declined the customer need to check with their bank account. Alternatively they can try a different payment method.

#

Also if the main concern is that they get to use the services first and then payments fail, it might be better to charge them at the start.

#

Additionally, if you are concerned about the legitimacy of the customer you can always do an on session payment and request for 3DS (https://docs.stripe.com/api/invoices/create#create_invoice-payment_settings-payment_method_options-card-request_three_d_secure). But this may impact your conversion rate.

elder furnace Mar 25, 2025, 1:19 AM

#

If we charge the user at the start and then have to refund it, it will also increase our refund rate
Will that flag us on stripe on our account?

serene magnet Mar 25, 2025, 1:34 AM

#

I know dispute rates are an issue but I can't be to sure about refund rates.

elder furnace Mar 25, 2025, 1:35 AM

#

So the best setup is to do what we are currently doing but to prevent more fraud we should either charge users initially or trigger 3DS manually?

#

Current setup of using setupintent and subscription/invoices is the right way?

serene magnet Mar 25, 2025, 1:37 AM

#

A payment is considered fraudulent when the cardholder didn’t authorize it (https://docs.stripe.com/disputes/prevention/fraud-types). Just because a charge fails, it doesn't mean that it's fraudulent. You will need to build in a process for charges that fail by retrying it or getting a different payment method.

elder furnace Mar 25, 2025, 1:38 AM

#

So we need to prompt the user or retry the invoice?

serene magnet Mar 25, 2025, 1:38 AM

#

Yeap!

#kavish_best-practices