CasuallyCaffeinated-ach-debit-testing

[deep bone]

How specifically are you testing this/what does saving your form do? With the new ACH debit integration you can do most tests through the hosted flow which surfaces a variety of bank accounts (that will map to different behaviors)

[fickle cobalt]

Normally, if a user submits the ACH save payment method form, as long as there are no errors, it links the user back to the parent component which displays all the the saved payment methods and their statuses. However, if Stripe returns an error:

const stripeResponse = await stripe.confirmUsBankAccountSetup(clientSecret, accountSetupData);
  if (stripeResponse.error) {
      setErrorMessage(stripeResponse?.error?.message); 
}```
Then I save that error message to a state variable and then displayed it in a separate component. Moreover, the form isn't submitted. 

However, when I use some test data like: 
```js
Account number: 000111111116
Token: pm_usBankAccount_noAccount
Routing number: 110000000
Behavior: The payment fails because no account is found.```

Which I found in that link I posted above, no error occurs and the form still submits. 

I assume this is because those error codes are scoped strictly to making payments via ACH, whereas I need to simply save ACH payment method information. So is there somewhere I can look to find testing dummy data with this scope in mind?

[deep bone]

Ah gotcha - you're just creating a PaymentMethod and not doing any verification or setup intent, right? As far as I know there isn't any test data that will do exactly what you need (because we don't do the validation when you just create the Payment Method).

[fickle cobalt]

Gimme just a bit of time to get back to you on this, gonna double check with my team

[fickle cobalt]

Sorry for the wait. A team member confirmed that we are indeed using Setup Intent in order to create the Payment Method, but verification only happens after submitting the form.

That being said, I was able to surface one specific error when the Routing Number some passes in, is invalid. Namely: payment_method_invalid_parameter .

For Account numbers that aren't part of the pre-approved list, Stripe returns payment_method_invalid_parameter_testmode it seems.

Would I be mistaken in assuming that these are the only error codes I could realistically expect to surface before the whole verification process goes through? Or are there any other ways to force Stripe to return a different error code before the full verification goes through?

[high sail]

Hi there 👋 taking over here as karbi had to step away.

Would I be mistaken in assuming that these are the only error codes I could realistically expect to surface before the whole verification process goes through? Or are there any other ways to force Stripe to return a different error code before the full verification goes through?
I don't think I understand the question. You create the Payment Method using that data and receive payment_method_invalid_parameter, is that correct?

[fickle cobalt]

All good! Thanks for the help.

Yes, essentially. When creating an ACH Payment Method, if I knowingly provide an invalid Routing Number, I get the error message: The payment details you provided are invalid. with the error code: payment_method_invalid_parameter. However, the same does not occur when I provide an invalid Account Number. Instead, I get the error code payment_method_invalid_parameter_testmode .

Is there an Account Number specific error code I can surface, similar to the one that exists for invalid Routing Numbers?

Sorry for the lack of clarity, let me know if my question still doesn't make sense!

[high sail]

Ahhhh, okay. No, that makes sense. I don't think there is an account-number-specific error code to surface, which is likely intentional for security reasons. The payment_method_invalid_parameter_testmode is interesting though. Do you have a request ID for that?

Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request

[fickle cobalt]

Sorry for the delay in my reply, was on my lunch break.

Let me see if I can find that request_id

Would this be it?

[lone rapids]

can you paste that request ID here?

the req_123 part

[fickle cobalt]

Sure thing: req_UnwNrITwVQDkNG

[lone rapids]

you have a typo right

you passed 00012345678

the right thing is 000123456789
(9 at the end)

the Request Log page tells you the full error msg: https://dashboard.stripe.com/test/logs/req_UnwNrITwVQDkNG

[fickle cobalt]

Oh, I understand that. That's what I expected

Not sure why two-shoes had requested the ID, but essentially I had asked if I could get a specific exception to be raised if the Account Number provided is incorrect, however, its understandable that for security purposes, that isn't possible

But I was testing to see what error I get back if I intentionally provide an invalid Account Number

[lone rapids]

if the Account Number provided is incorrect
I think the closest to that is the pm_usBankAccount_noAccount bank acct info from https://stripe.com/docs/payments/ach-debit/accept-a-payment#test-account-number

[fickle cobalt]

Yeah, when I submit the form with those credentials, the form still successfully submits. Here's the Request ID req_R5NJG86tqrct6g

I assume that is expected?

[lone rapids]

that SetupIntent was not authenticated

it was only confirmed

it is in status: requires_action

the error should happen when you try to authenticate it in test mode which actually attempts the payment

[fickle cobalt]

Got it, that makes sense.

Just for the sake of the simplicity, what does the status change to one the SetupIntent is authenticated? "status": "succeed" ?

[lone rapids]

from status: requires_action

• if succeeds, then status: succeeded
• if declines, then status: requires_payment_method (so a new PaymentMethod can be tried on the SetupIntent/ PaymentIntent)

[fickle cobalt]

Ah, okay. I see. Well, thanks for the info, I'll convey it to my team.