#ctodan

1 messages · Page 1 of 1 (latest)

left rockBOT
deep tulip
#

Hi! Let me help you with this.

#

Could you please share the PaymentIntent ID pi_xxx?

knotty star
#

i think we tweaked something and its possible causing issues

#

yes

#

pi_3NUqDIJmq474uon80VTvrk9S

#

heres an example of one that was counted: pi_3NUhGIJmq474uon807hK8Fo1

#

the only distinction i notice is the source for the not counted one is US Bank Account but the source for the later is ACH debit

#

const subscription: Stripe.Response<Stripe.Subscription> =
await this.stripe.subscriptions.create({
customer: stripeCustomerId,
items: [{ price: subscriptionPlan.stripePriceID }],
payment_behavior: "default_incomplete",
payment_settings: {
payment_method_types: ["us_bank_account", "card"],
save_default_payment_method: "on_subscription",
},
collection_method: "charge_automatically",
expand: ["latest_invoice.payment_intent"],
})

#

const paymentMethodId: string = await this.getBankPaymentMethodId(user)

    const latestInvoice: Stripe.Invoice = subscription.latest_invoice as Stripe.Invoice
    const paymentIntent: Stripe.PaymentIntent =
        latestInvoice.payment_intent as Stripe.PaymentIntent

    await this.stripe.paymentIntents.confirm(paymentIntent.id, {
        payment_method: paymentMethodId,
        mandate_data: {
            customer_acceptance: {
                type: "online",
                accepted_at: new Date().getTime(),
                online: {
                    ip_address: ipAddress,
                    user_agent: userAgent,
                },
            },
        },
    })
#

theres most of the code for it

#

we are manually connecting an old bank source from plaid

deep tulip
knotty star
#

I guess the issue is we used to see them as successful in the dashboard on the app

#

Or not successful but they’d show in the payment count

#

Now we don’t see that

deep tulip
#

I don't know of anything changing there. In any case, you can't count these funds as your balance before the transaction has succeeded.

knotty star
#

We definitely made a code change here

#

There seems to be a nuanced difference with these users payments being marked as us_bank_account vs ach_debit

deep tulip
#

Did you change from ach_debit to us_bank_account before the behavior changed?

knotty star
#

it seems so, but not intentionally/we werent and arent aware of the nuance of the difference

#

the change was to add cards as a payment option in addition to ACH

deep tulip
#

ach_debit is deprecated now in favor of us_bank_account. If you are able to acommodate your app to the new logic it would be a better solution.

knotty star
#

Is us_bank_account the same thing effectively?

#

we never used to specify ach_debit

#

i just seemed to go to that

#

also the bank is connected to plaid with the old sources api

#

like so:

#

const stripeBankAccountToken = await plaidService.createStripeBankAccountToken(user)
const stripeCustomer = await this.createOrGetCustomer(user._id.toString())

        const bankAccount = await this.stripe.customers.createSource(stripeCustomer.id, {
            source: stripeBankAccountToken.stripe_bank_account_token,
        })
deep tulip
deep tulip
knotty star
#

we have to use plaid tho because its used with another partner for funding investment accounts in our app

#

is the plaid option still compatible with us_bank_account

#

also can you confirm that its expected to not show in gross volume or payment in the dashboard until its successful? this was not the behavior of the ach_debits

#

also im worried these payments arent processing correctly: pi_3NUqDIJmq474uon80VTvrk9S

#

the old ones from before this release show a "Payment pending" in the timeline instead of just "Payment started"

deep tulip
deep tulip
knotty star
#

^im worried about this distinction i suppose

deep tulip
#

Could you please share the ID of the one on the right?

knotty star
#

pi_3NUhGIJmq474uon807hK8Fo1

deep tulip
#

I see that it's pending in your Dashboard.

#

I mean the one that only have "Payment started".

knotty star
#

Ah that’s the first one

#

py_3NUqDIJmq474uon80hXMdrwy

deep tulip
#

I see now.

#

I think this might be an bug on the Dashboard side. I will report this to the relevant team.

knotty star
#

But just to be 100% sure the payment is ok? And should move to successful (barring disputes and the normal ach problems ofc)

deep tulip
#

Correct.

left rockBOT
knotty star
#

Is there also any way we can get confirmation on why the us bank account ones don’t show up under gross volume/payments yet? But the ach_debit ones do?

hollow badger
#

Unfortunately we don't know much about the dashboard here. If you reach out to our support team they may have more info for you here

#

https://support.stripe.com/?contact=true

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

knotty star
#

Do you know the nuance of the differnce between ach_debit and us_bank_account?

#

I def changed some parameters around this, but why would it have defaulted to ach_debit before?

#

const subscription: Stripe.Response<Stripe.Subscription> =
await this.stripe.subscriptions.create({
customer: stripeCustomerId,
items: [{ price: subscriptionPlan.stripePriceID }],
payment_behavior: "default_incomplete",
payment_settings: {
payment_method_types: ["us_bank_account", "card"],
save_default_payment_method: "on_subscription",
},
collection_method: "charge_automatically",
expand: ["latest_invoice.payment_intent"],
})
adding payment_method_types here was a new change

hollow badger
#

Do you have the ID of a subscription or payment or something else that is marked as ach_debit rather than us_bank_account? I am not immediately sure on the difference, to my knowledge the new APIs should consistently use us_bank_account so those specific objects can help me look in to times where it isn't

knotty star
#

yes sure, there are some earlier in the chat. let me get you them again

#

us_bank_account: pi_3NUqv2Jmq474uon81Rbi7ev2
ach_debit:pi_3NUhGIJmq474uon807hK8Fo1

hollow badger
#

Apologies, thank you for resending them. Looking at those object IDs now

#

Still completely confirming this, not finding much in our docs unfortunately

knotty star
#

that change was def made

#

but the consequence was not intentional

#

aka was not even aware of a difference between ach_debit or us_bank_account

#

i could add ach_debit as one of the payment_method_types but im not actually sure it would change anything?

#

Also seems like i should be using us_bank_account anyways? as ach_debit is deprecated? so maybe what im doing now is more correct?

#

The only thing that irks me is that pending us_bank_account payments are not being counted in gross volume or payment counts yet when ach_debit one were being counted

hollow badger
#

I'm still having trouble finding info on this. All the relevant docs that I am finding mention ach_debit. I will check in with my colleagues and see what we can find

#

And as far as you can tell, these payment methods both work for you, the difference is mainly how it counts in the dashboard?

knotty star
#

It seems to be the main difference yea

#

And the timeline info is not showing Payment Pending in the us_bank_account variant

#

also not yet sure if the us_bank_account works yet -- just havent seen one move to successful yet

#

internally im also not sure what the difference is (they both use ach right)

hollow badger
#

us_bank_account definitely works, it has been around for some time. Interestingly you can create an invoice with both and it will only show one payment method option on the actual hosted invoice page.

knotty star
#

Is the dashboard situation expected behavior for you?

#

would you expect the payments/gross volume to only get counted once they move to successful?

#

is there a way to tell in test mode? pi_3NUidaJmq474uon81syXaxZF moved to successful too quickly to check

hollow badger
#

Not as far as I know unfortunately. I thought we had numbers that delayed the actual payment but I am not seeing them in our testing doc anymore

hollow badger
knotty star
#

Is there a way I can test this in test mode?

#

Like make a payment move to success a little slower

#

Rather than just jumping to successful

hollow badger
#

That is what I was speaking to with this message:

Not as far as I know unfortunately. I thought we had numbers that delayed the actual payment but I am not seeing them in our testing doc anymore

knotty star
#

Ohh sorry missed that I see

#

So overall would you recommend leaving this as is now

#

With us_bank_account?

#

Also a little unsure about the dynamic with these bank accounts being legacy created with the createSource api

hollow badger
#

Yeah we're still figuring that out. It does look like ach_debit may be the older API and us_bank_account the newer one. In which case us_bank_account would be the one to use. Still figuring out exactly what is happening with my colleagues though

knotty star
#

ok let me know what they say

#

i did just test again in test mode

#

there is a one minute or so delay between pending and successful and did not see the bump in gross volume while in pending

hollow badger
#

Okay, so finally figured out what makes ach_debit show up vs not on the payment intent's payment_method_types.

It represents the Sources API version of ACH DD. It will show up if the Customer that you are using has an ACH DD Source attached to them

#

And also important is that in your call that did not have ach_debit you specifically specified payment_method_types in the API which overrides your default account settings and only uses the PMs provided.

#

Also it looks like ach_debit is no longer supported by the hosted invoice page. So if you want to use ACH with your invoices, you will want to use us_bank_account

knotty star
#

ok so before specifying payment_method_types: ["us_bank_account", "card"] in the create subscriptions call, the account would default to the older ach_debit method because the PM was connected via the legacy createSource api, correct?

#

Once we specified the payment_method_types, and explicitly passed the payment_method_id in the stripe.paymentIntents.confirm method, it started using the us_bank_account payment method instead, even with the payment method connected via plaid and the old sources api?

hollow badger
#

Yes, though now that I test it some more, it looks like us_bank_account will still show up if you have it turned on in your settings. So you don't need to specify payment_method_types, you can use that if you want, but the dashboard settings are also an option if you find them easier to manage.

#

payment_method_types in the create subscription call was the main factor that made us_bank_account show up

knotty star
#

i think i set it manually because i was seeing an issue earlier on

#

in theory, could switch to specify ach_debit in the payment_method_types instead?

#

also there is no way to make this connected bank account show up in the mobile payment sheet right?

hollow badger
#

Yes, you can specify both but ach_debit won't show up on the invoice page or in the payment element if you use it

#

You can still use that source to confirm the payment intent, but our UIs won't display it

knotty star
#

ok got it, and then separately, no one has an explicit knowledge/confirmation on they way the us_bank_account is counted on the dashboard right with respect to payments/gross volume?

hollow badger
#

Yeah unfortunately my team is still unclear on that. Our support team should be able to answer it or at least move your question to a team that can answer it

knotty star
#

i tried them but got a frankly incorrect sounding answer

left rockBOT
knotty star
#

they were saying it refreshes daily but im certain thats not the case because ive seen it update live for the old ones

#

i have another hunch about this maybe you can confirm

#

for the us_bank_account pending charges, there is no balance_transaction yet

#

❯ stripe payment_intents retrieve pi_3NUtNIJmq474uon80NNdqtjt --live --expand='latest_charge.balance_transaction'

#

vs:

#

❯ stripe payment_intents retrieve pi_3NUiKaJmq474uon80JcHMGQ5 --live --expand='latest_charge.balance_transaction'

#

is that expected

feral monolith
#

Hi 👋

I"m stepping in as @hollow badger needs to go.

knotty star
#

note the second one used ach_debit and the first one used us_bank_account

#

hi @feral monolith, need me to give you a quick tldr to catch up or you reading through?

feral monolith
#

I'll just read

#

I'm looking into the difference in behavior but, if that is expected, that would potentially impact how the Dashboard represents these transactions

#

Okay I have confirmed with my colleagues that this is expected behavior and is one of the design differences between the two payment methods

knotty star
#

ok cool, that surely has a big impact on how the dashboard behaves right?

#

any reason for that design change?

#

And so we can expect the balance transaction to be generated once the payment moves into successful right?

feral monolith
#

that surely has a big impact on how the dashboard behaves right
As my colleague mentioned, I can't speak to that

#

any reason for that design change
Making the balance transaction occur later ensures it more accurately represents the balance in your Stripe account, since a pending charge means you don' t have the funds yet

#

And so we can expect the balance transaction to be generated once the payment moves into successful right
Correct

knotty star
#

ok got it thanks so much for all the help!