#amer-paymentintent-pmt

1 messages ยท Page 1 of 1 (latest)

urban lakeBOT
iron hazel
#

Hi ๐Ÿ‘‹ the error message included in the response to that request seems to indicate the type of the default source on the Customer does not match the accepted payment_method_types of the Payment Intent.

It looks like you're using automatic payment methods, so have you enabled the associated payment method types in your dashboard settings?
https://dashboard.stripe.com/test/settings/payment_methods

molten silo
#

@iron hazel im creating a token and in way to use the token in the payment intents

iron hazel
#

But did you enable the payment method type that aligns with the type of tokens you're creating? If not, since this is testomde (they will need to be activated to work in livemode) you can manually pass the necessary types via payment_method_types
https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_types

The request's error has more specific context indicating your Payment Intent is only accepting card payment methods, but you're trying to pay with a ach_debit source.

molten silo
#

i enabled ACH Direct Debit and still got same error

#

req_ij8yVdwVnslbqO

#

@iron hazel does it take time to be active

iron hazel
#

Does it have a green check beside it in the dashboard and say "On"?

molten silo
#

@iron hazel ^

iron hazel
#

I would recommend double checking your logged into the same account there as the one that is making the request. Also, does using passing payment_method_types explicitly suppress the error?

molten silo
#

I'm logged into the same account cause if I navigate to logs. I do see my logs in that account. @iron hazel

iron hazel
#

Okay, I would suggest trying to explicitly declare payment_method_types then.

molten silo
#

how to do this using the token? @iron hazel i dont want the payment method to be saved under the custom thats why im using a token.

#

same flow works fine with using the charge object instead of the payment intent

iron hazel
#

Not on the token, on the Payment Intent, by providing the payment_method_types parameter with a list of the values that you want to accept.

If you omit payment_method_types we attempt to automatically determine which enabled and ready to use payment method types should be accepted by the Payment Intent, you can override this behavior by using that parameter.

molten silo
#

i got this error @iron hazel

iron hazel
#

It doesn't look like you sent an array as that parameter was expecting. How are you structuring the request from your side? Since you're not using one of our SDKs, I think you're going to be more careful with how you structure your inputs. Does that error resolve if you follow an approach more like the one we suggest when using cURL?

The snippet in this section has an example of a cURL request passing payment_method_types:
https://stripe.com/docs/payments/ach-debit/accept-a-payment?platform=web&ui=API#web-create-payment-intent

molten silo
#

@iron hazel i got this error now

#

"error": {
"code": "payment_intent_incompatible_payment_method",
"doc_url": "https://stripe.com/docs/error-codes/payment-intent-incompatible-payment-method",
"message": "The provided Customer's default_source's type is not allowed by the PaymentIntent's payment_method_types. In this case, the Customer's default_source was of type ach_debit, and the PaymentIntent's payment_method_types are: bank_account. Try again with a different source or use a different value for payment_method_types.",
"request_log_url": "https://dashboard.stripe.com/test/logs/req_5VLyMpNDPdstCN?t=1676647711",
"type": "invalid_request_error"
}

#

@iron hazel it worked in this request req_IOsDhOU5GWooXh

iron hazel
#

You do not need to tag me in every message, I get notifications of replies already.

molten silo
#

sorry about that but it worked in this request req_IOsDhOU5GWooXh when i changed type to ach_debit

iron hazel
#

I was just about to ask if you had tried passing the ach_debit value that the error showed instead of something else, looks like that did it

molten silo
#

i have a question the status is succeeded. Per the documentation it says will take up to 4 to 5 days

iron hazel
#

I believe that is expected since this was done in testmode.

molten silo
#

we want to test the production behavior. is there a way to do that?

iron hazel
#

I'll need to double check, but the difference would be the status field being processing instead of succeeded.

molten silo
#

Can you please check? We want to demo the functionality to the business before they go live. The business wants to see what will happenen for each of those statuses

iron hazel
#

What happens if you use us_bank_account as the payment method type rather than ach_debit? Do you see the same behavior?

molten silo
#

let me check

iron hazel
#

Thank you! Tokens/Sources/Charges are used for our older approach where Payment Methods/Payment Intents are used for our new version of ACH debits, so I'm wondering if there are some edge cases that the test bank accounts don't handle well when they're used across those flows.

molten silo
#

if i use us_bank_account, i get this error "message": "The provided Customer's default_source's type is not allowed by the PaymentIntent's payment_method_types. In this case, the Customer's default_source was of type ach_debit, and the PaymentIntent's payment_method_types are: us_bank_account. Try again with a different source or use a different value for payment_method_types.",

iron hazel
#

Hm

#

Taking a step back to look at the bigger picture, is this a new integration that you're building or doing maintenance to an existing one?

molten silo
#

I'm building new integration inside Salesforce using stripe rest API. I cant use stripe libraries cause salesforce does not support them. Previously the client was using chase for online banking and wants to switch to stripe.

iron hazel
#

Gotcha, is there a particular reason you were drawn to our legacy Tokens/Sources approach rather than our new version of ACH that uses Payment Methods and Payment/Setup Intents?

#

If not, I would strongly encourage you to consider refactoring to use our new flow.

molten silo
#

part of the business requirement is to create a payment with saving the payment method and customer. there is no straight way to create a payment method and then create payment intent. I found out that we have to create a customer, create a payment method and attach a payment method to a customer, then create a payment intent.

#

here is the digram im working with

iron hazel
#

You would use Setup Intents to create Payment Methods that you plan to use to fulfill payments in the future without processing a payment while collecting payment method information. Our recommended flow for that is walked through in this guide:
https://stripe.com/docs/payments/ach-debit/set-up-payment

molten silo
#

i want to process payment at the same time to be able to tell the customer if the payment went through or no

iron hazel
#

Oh, then you process a Payment Intent that has setup_future_usage set based on how you plan to use the created Payment Method in the future. (I'm pretty sure ACH supports that, double checking)

molten silo
#

to my question, can we create payment method and payment intent without creating a customer

#

sorry without customer

iron hazel
#

Do you want to be able to reuse the Payment Method in the future?

molten silo
#

no

#

just on time payment

iron hazel
#

Then yes, you can create a Payment Intent without referencing a Customer. How are you collecting payment method details from your customers, are you using Stripe Elements?

molten silo
#

no, I'm not. we are using stripe rest API only. I want to create on-time payment either credit card or bank account

iron hazel
#

Gotcha, so you're collecting payment method details from your customers directly, and taking on the compliance burdens that come with handling those details.

molten silo
#

yes

iron hazel
#

Since you're collecting and handling payment method details directly, your approach will need to deviate from our documentation as those typically are written assuming one of Stripe's frontends will be used for collecting payment method information. So some trial and error may be necessary.

molten silo
#

why u said use us_bank_account vs ach_debit

iron hazel
#

us_bank_account is the newer nomenclature for ACH

molten silo
#

ok

#

let me try

iron hazel
#

Hm, now I'm wondering if that won't work because the bank account wouldn't have been verified first.

molten silo
#

Okay, i want to work with a credit card and this try bank account. I'm getting this error with credit card

#

is there a setting we can turn on to bypass this error?

iron hazel
molten silo
#

ok

hearty reef
#

amer-paymentintent-pmt

molten silo
#

i turn the setting on and i was able to process one time credit card payment using the payment intent

#

now im testing the bank account

dry path
#

๐Ÿ‘‹ stepping in

#

Let me know if you run into any issues

molten silo
#

You recommend for bank account to use us_bank_account instead of ach_debit cause is the newer nomenclature for ACH

dry path
#

Yep

#

ach_debit is our legacy payment method for ACH

molten silo
#

I got an error

#

this is the body im sending

#

amount=10000&currency=usd&confirm=true&payment_method_data%5Btype%5D=us_bank_account&payment_method_data%5Bus_bank_account%5D%5Baccount_holder_name%5D=John+Doe&payment_method_data%5Bus_bank_account%5D%5Baccount_holder_type%5D=individual&payment_method_data%5Bus_bank_account%5D%5Brouting_number%5D=110000000&payment_method_data%5Bus_bank_account%5D%5Baccount_number%5D=000123456789

dry path
#

Looking

#

You can see that account_holder_name isn't a parameter

molten silo
#

ok let me try that

#

okay i got this error now

#

"error": {
"message": "The PaymentMethod provided (us_bank_account) is not allowed for this PaymentIntent. Please attach a PaymentMethod of one of the following types: card. Alternatively, update the allowed payment_method_types for this PaymentIntent to include "us_bank_account".",
"request_log_url": "https://dashboard.stripe.com/test/logs/req_IhdkpvunRl76dD?t=1676654943",
"type": "invalid_request_error"
}

dry path
#

Okay so that error seems pretty self-explanatory no?

#

You didn't pass payment_method_types to your PaymentIntent creation request

#

That is a required parameter

#

It defaults to card if you omit it

#

So it is required here

molten silo
#

it did create payment intents record but i got an error with that req_OMYUJDDW9LjLwM

#

This PaymentIntent requires a mandate, but no existing mandate was found. Collect mandate acceptance from the customer and try again, providing acceptance data in the mandate_data parameter.",

dry path
#

Yep so the mandate_data parameter is also required for ACH Debit as you must collect mandate acceptance from your customers.

molten silo
#

what is that mandate_data parameter

dry path
molten silo
#

can u take look at this request req_UWN1FCh2TdMh9t

#

i passed metadata but im getting Received unknown parameter: payment_method_data[mandate_data]

dry path
#

mandate_data is top level

#

Not within payment_method_data

molten silo
#

ok i see

#

it worked but the status is requires_action, do you know why? req_cQqFetv5IpKAhd

dry path
#

Which would be the option if you create/confirm the PaymentIntent server-side

molten silo
#

We are using rest api and collecting bank account payment method details from the customers directly with that we want to create an on-time payment and respond back to the client on the same moment. what u reccomant Instant Verification or Microdeposi?

dry path
#

Yeah if you want to be able to create the payment instantly then you should use Stripe.JS for confirmation here and leverage Instant Verification

#

Otherwise microdeposit verification is required and takes 1-2 biz days

molten silo
#

we can not use Stripe.js cause is not supported by Salesforce platform and thats why we are using rest api. Does instant Verification only work for Stripe.JS?

dry path
#

Yes it does

molten silo
#

this is not good

#

using Microdeposi will take 1 to 2 days

#

and that only option we have for this business requirement. using rest api and collecting bank account payment method details from the customers directly with that we want to create an on-time payment and respond back to the client on the same moment.

dry path
#

I mean you can still respond back at that moment

#

But you will respond telling them they need to verify their account via microdeposits which will be in their account in 1-2 days

#

Then you need to bring them back on-session to perform that verification

molten silo
#

Previously, i used the charge api with ach_debit type and i got respond right back with success

#

do you know why?

dry path
#

The same thing was true with ACH_Debit as well

#

Microdeposits were required in the same way

#

Unless you used Plaid perhaps?

molten silo
#

req_IOsDhOU5GWooXh

dry path
#

Which performs bank account verification for you

molten silo
#

i called verifyBankAccountRequest api

dry path
#

Yeah so then you did the same thing that you will need to do for us_bank_accounts

#

Which is verify via microdeposits

molten silo
#

response came back within seconds

#

do you know why?

dull idol
#

๐Ÿ‘‹ I'm hopping in since bismarck has to head out soon - give me a minute to catch up

molten silo
#

ok

dull idol
#

The verification once you have the actual microdeposit amounts is done instantly, but it takes 1-2 days for those microdeposits to actually reach the bank account. Does that make sense? In testmode you don't really feel that delay because we have hardcoded values that you'll use and you don't have to wait for those microdeposits to reach the account

molten silo
#

okay this make sense

#

right now we are collecting data and sending them to the stripe through create payment intents rest api directly with one api call. in order to implement microdeposit do i need to create a customer

dull idol
#

Yes, I'm pretty sure you need to attach the Bank Account to a Customer to verify it

molten silo
#

microdeposits verification endpoint is https://api.stripe.com/v1/customers/' + customerId + '/sources/' + bank_accounId + '/verify' . Since im create on-time payment through payment intents api. I dont have the bank account id.

#

this is what im getting from payment intent req_cQqFetv5IpKAhd

dull idol
#

You can get it though - if you're not passing in the BankAccount ID I assume you're relying on the default set on the Customer so you'll need to retrieve the Customer and check for their default_source

molten silo
#

It's one time payment im passing the payment info and bank info to payment intent api as you see in this request req_cQqFetv5IpKAhd

dull idol
#

Ah! I see - give me a minute

molten silo
#

ok

dull idol
molten silo
#

ok let me try

#

"code": "parameter_missing",
"doc_url": "https://stripe.com/docs/error-codes/parameter-missing",
"message": "Missing required param: descriptor_code.",
"param": "descriptor_code",
"payment_intent": {
"id": "pi_3McZ32LcZsW8iWbK2ia6iGsM",
"object": "payment_intent",
"amount": 10000,
"amount_capturable": 0,
"amount_details": {
"tip": {
}
},

#

it's an optional on the api.

#

what is descriptor_code

dull idol
#

Actually one second, let me take a closer look at that PaymentIntent

molten silo
#

req_U7RCcJj92On9EU it worked status is progress. this will take 4 to 5 days to be set to success or failure

dull idol
#

Yeah I see what the issue was - if you look at the request you made to create the PaymentIntent (https://dashboard.stripe.com/test/logs/req_Ug4xsFAEst5ZYb) you can see under next_action.verify_with_microdeposits.microdeposit_type it says descriptor_code, so that's why you got the error when you tried to use amounts

molten silo
#

im confused

#

in this request i created payment intend req_ThKK9HtPISXtnA and payment intent status is requires_action then, i did microdeposits verification in this request req_oyDLttw8ecaTEV and payment intent status is processing

dull idol
#

What specifically are you confused by? The fact that the status is processing?

molten silo
#

got confused about your previous comment. do i should something different in my call?

#

also, regarding the processing status, this will take 4 to 5 days to be set to success or failure. is right?

dull idol
#

What you're doing is correct - I was just trying to clarify why setting amounts didn't work in your initial request

molten silo
#

oh okay

#

i have descriptor_code in my call set to SM11AA - Simulates verifying the account.

#

once we go live what descriptor_code should be set to?

dull idol
#

That's something the user provides - they'll see it in their bank statement

molten silo
#

it can be any text in live

dull idol
#

yes

molten silo
#

regarding the process status, Usually will take up to 5 days for it to get updated?

dull idol
#

yup!

molten silo
#

okay Thank you so much for the help