#HK6-card-network-inforamtion

1 messages ยท Page 1 of 1 (latest)

civic cosmos
#

Hi there ๐Ÿ‘‹ this is very interesting, do you have the IDs for some invoices where you're seeing this that we can take a closer look at?

elder cedar
#

Yes

#

Let me check

#

in_1JqnftED5xkfDv2cBOklj41e

#

this one had a successful charge

#

in_1JqkqwED5xkfDv2cHffAoBFT
This one failed

elder cedar
#

Any findings?

queen wave
#

Looking

#

Sorry just catching up here

#

The payment failures here are being decline by the bank, we can't really say why in more detail than that.

I;m not sure what you mean about the card network/brand, the failing payment example you shared does show you visa in the PM creation request, for example:
https://dashboard.stripe.com/logs/req_1GNr2wtdBaW7Mu

elder cedar
#

Yes but when we get the invoice data from export, columns are empty

#

so it looks like there is some things not stict==trching together

#

and for these for whihc the info is empty, failure rate is much higher

queen wave
#

What do you mean by export here? The data is available in the API, are you retrieving it yourself or using a dashboard export or something else?

elder cedar
#

here I checked with the dashboard export

stone inlet
#

@elder cedar I'd recommend chatting with our support team: https://support.stripe.com/contact we don't really discuss Dashboard exports here we focus on code related questions from devs

elder cedar
#

yes that was my point

#

we observe something in data. Export does not seem to be the problem

#

wanted to check if when creating subscription, in code, there could ne some information that could be required in some cases that we may have missed

#

or when creating the customer or payment method

#

which could create that situation

stone inlet
#

yeah I'm sorry I'm quite lost despite all the write up on what the question even is and what's missing. Can you clarify exactly what you are asking and what your code is doing?

elder cedar
#

The code is creating:

  • customer,
  • payment method,
  • attaching the payment method to the customer,
  • creating it for off session
  • authorizing and capturing a payment,
  • if selected by the customer we create a subscription
#

but we realise that when some of the subscriptions get billed, (getting the data of the invoices), some of the invoices do not contain card info. These have a very high fail rate

#

the ones for which the card info is available at invoice level (data wise) have a normal fail rate

#

So it looks like, when the data is not at the invoice levels subscription payments tend to fail

#

so we are trying to figure out if this is due to some information we would not pass correctly at some point

#

The fail rate on these ones is so high that it does not look like random

#

(85% of failures)

stone inlet
#

I'm sorry this is still so abstract ๐Ÿ˜ฆ

#

Also this flow is absolutely not the right/common integration path for subscription creation at all

elder cedar
#

what do you mean?

#

I mean concerning the integration path

#

for the abstraction level I get it ๐Ÿ™‚

stone inlet
#

1/ Create Subscription with payment_behavior: 'default_incomplete'
2/ Confirm the underlying PaymentIntent client-side

#

that's how you should do this

elder cedar
#

ok I'll check that out

#

Just to clarify the payment intent is not related to the subscription itself

#

in our use case

#

same in yours

#

?

stone inlet
#

Why wouldn't it be?

elder cedar
#

because customer pays for an order

#

thus the payment intent

#

but after they can subscribe to a service

#

to guarantee the product

#

so they start a subscription with a trial

#

after paying

stone inlet
#

But why not have them pay as part of the subscription though/

#

Ultimately in your example it should be
1/ Create a PaymentIntent with setup_future_usage: 'off_session'
2/ Confirm PaymentIntent client-side => will attach the card if succeeds
3/ Later create a Subscription server-side with a trial after marking that card PaymentMethod as the default on the customer

elder cedar
#

yes

#

that's what we do

#

your explanation is clearer than mine

#

but doing this we get these strange invoices missing the card network info and so on

#

for which failure rate is very high

stone inlet
#

what does "missing the card network" mean though?

#

You still didn't really explain your real question unfortunately. Having a clear understanding in one sentence of your exact issue would really unblock this thread

#

If you said: Invoice X shows Y and Z but Invoice T has no info in Y, it would unblock this thread in a few seconds

elder cedar
#

Invoice : in_1JqkqwED5xkfDv2cHffAoBFT
has no value in the Network column when we look at the invoice data

#

even though there is a charge assoiated to it

#

Invoices which present this characteristic actually have a 85% failkure rate

icy swallow
#

Hello! I'm taking over for @stone inlet, getting caught up now...

#

Can you clarify what you mean by "the Network column"? Where are you seeing this column?

elder cedar
#

In the exported data

#

invoice exported data

icy swallow
#

Exported from where?

elder cedar
#

dashboard

#

as we noticed that we had sone high failure rate

stone inlet
#

We keep hitting problems: Please focus purely on the API and nothing else

#

what do you see in the API

icy swallow
#

Yeah, we can't really help with Dashboard exports here.

#

We can help with the API though!

elder cedar
#

I will check via the API themn

#

\troubleshootinbg with the dashboard was just a faster way to investigate

icy swallow
#

Faster way to investigate what? The reason for the payment failures on your Invoices? Is that the problem you're trying to solve?

elder cedar
#

I am trying to understand if this is the symptom of something we do wrong in our way to create the subscription via the API

#

We are using the API to create what I described above

#

We obeserved some high failure rates

#

So I got the data from the dashboard to quickly investigate if it was related to a bank a network or whatever

#

And I noticed this

icy swallow
#

Can you give me a few examples of the failures you're trying to investigate? Invoice or Charge IDs?

elder cedar
#

sure

#

in_1JqkqwED5xkfDv2cHffAoBFT
in_1JqkQbED5xkfDv2cRBZ57QyE
in_1JqjgRED5xkfDv2ch9ktXRZS
in_1JqjfFED5xkfDv2cRlaFyn0s

in_1JqfqKED5xkfDv2cBT9xFakz

in_1JqcrxED5xkfDv2cObSoaSAR
in_1JqY24ED5xkfDv2cIKTvCqFf
in_1JqQcMED5xkfDv2c97K4OMWl

in_1JqQc8ED5xkfDv2cdvvGWSk1

in_1JqQc6ED5xkfDv2cwmqool50
in_1JqQb4ED5xkfDv2cLiiyh68G

in_1JqQb4ED5xkfDv2ciAcAchco

in_1JqQaUED5xkfDv2c00Zrw3MI

#

All of these fail, and have no network info at invoice levekl

#

(they are part of the 85%)

icy swallow
#

Looking...

elder cedar
#

thanks

icy swallow
#

The first and third Invoices there have declines coming from the card issuers, and details about those are on the associated Charges. The second one appears to have succeeded, so not sure what you're looking for with that one.

#

Does that information help?

elder cedar
#

not really. Actually I am not sure my thing is a real lead... Look at the screenshot

#

It is a sample of the download

#

as you can see all these invoices have a charge associated to it

icy swallow
elder cedar
#

some have info in the network column

#

Ok I'll check

#

Not sure the problem is in the export though. It is in the underlying data

#

but this is also better to talk to support for that?

#

And this kind of missing data does not make you think of something?

#

that was my hope ๐Ÿ™‚

icy swallow
#

I can't speak to how to the export from the Dashboard works, so I can't even confirm the data is "missing" or not. I can tell you I don't see any missing data from an API point of view.

elder cedar
#

Ok

#

actually that's rather good news

#

we'll look elsewhere

#

and check with support