#bishop_api
wise estuaryBOT
👋 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/1266072165669797889
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
deft torrent
This is the error we're encountering:
{
"error": {
"message": "No valid payment method types for this Payment Intent. Please ensure that you have activated payment methods compatible with your chosen currency in your dashboard (https://dashboard.stripe.com/settings/payment_methods) or specify payment_method_types",
"param": "payment_method_types",
"request_log_url": "https://dashboard.stripe.com/logs/req_XGIm89t2jPnJpQ?t=1721924805",
"type": "invalid_request_error"
}
}
sonic kestrel
Hi 👋
I"m taking a look at this. It is a rather strange error.
Okay... I am seeing some internal error messages that suggest it might have to do with the fact that you are passing both a payment_method and automatic_payment_methods.enabled=True
But if that's the case, we really need to fix that error message.
deft torrent
ok, we are looking into it on our side now. This is working with test cards
sonic kestrel
Sorry, wrong thread
deft torrent
We are about to make the change and test on our end, but we believe this is something that Stripe has changed in the last 48h. This was working with test cards, and now the same code is failing with test cards.
sonic kestrel
Can you share examples of both
- request that is failing with this message
- request that succeeds with the same parameters
?
deft torrent
req_le6ADlX1QoyCyY
This is failing with this message
We got rid of the duplicate payment method delcaration
sonic kestrel
We got rid of the duplicate payment method delcaration
No you didnt
Also testing in Live mode is against Stripe terms of service
and you could be blocked for it
deft torrent
{
"description": "Test",
"capture_method": "manual",
"automatic_payment_methods": {
"enabled": "True",
"allow_redirects": "never"
},
"currency": "usd",
"customer": "cus_",
"transfer_data": {
"destination": "acct_"
},
"payment_method": "pm_",
"on_behalf_of": "acct_",
"amount": "100"
}
sonic kestrel
Here are the parameters I am seeing
{
amount: "100",
automatic_payment_methods: { // <- This is a duplicate since you already pass the payment_method
allow_redirects: "never",
enabled: "True",
},
capture_method: "manual",
currency: "usd",
customer: "cus_QXW2u713eDhrBN",
description: "Test",
on_behalf_of: "acct_1PgC8VQTJgqnqveS",
payment_method: "pm_1PgUGLKj7W6BzSLX3tLfxQNp", // <- if you have this you don't pass automatic_payment_method
transfer_data: {
destination: "acct_1PgC8VQTJgqnqveS",
},
}
ok.. sorry, this is the first time we're trying to make this work with a real credit card. it was working yesterday with test credit cards in Test Mode. We will make further changes in Test Mode, if you can help us identify the issue.
sonic kestrel
Well for starters, I recommend using either a saved Payment Method or automatic_payment_methods
deft torrent
ok, we will make that change. That change we just made was to get rid of this:
"payment_method_options": {
"card": {
"capture_method": "manual"
}
},
"capture_method": "manual",
"payment_method_options": {
"card": {
"capture_method": "manual"
}
},
We had capture_method: manual listed twice, I presume that is not necessary either?
sonic kestrel
Definitely not. HOwever, I am also seeing some interesting internal messages as well
"You do not have the capabilities required for payment method `card`"
,"link":"You do not have the capabilities required for payment method `link`"
Did Stripe deploy major updates in the last 24h? This has been working for weeks for us.
in Test
Are those capabilities on the connected account or the platform account?
(the missing ones)
sonic kestrel
Oh, there it is 🤦
The charge is a Destination Charge so it occurs on the Platform
The platform only has capbilities for transfers and payouts, no payments of any kind
Sorry for mixing that up.
I bet, if you can find a successful payment, it was being made directly on the Connected Account
deft torrent
Here is a successful request:
req_GrTRvIHoRAHwil
in test mode
it has both automatic_payment_methods, and the specified payment_method, and I believe it is going through a destination charge
We've been using destination charges for months (in test)
Where can I see/configure the capabilities for the platform account?
sonic kestrel
Hmmmm....okay now I'm really confused why it would show up as lacking capabilities. I checked the Payment settings for the Platform and you have multiple payment methods turned on.
Quick question. What happens if you use the same Connected Account from the successful request?
acct_1PdEyFQRWza8DE9f
deft torrent
It would be a very difficult test for us to run a specific account ID like that. We're using the stripe SDK in .net and not making direct REST calls
sonic kestrel
Sorry but I don't get that at all. While my .NET integration is pretty rudimentary it still seems pretty simple
var options = new PaymentIntentCreateOptions
{
Amount = 1000,
Currency = "usd",
AutomaticPaymentMethods = new PaymentIntentAutomaticPaymentMethodsOptions
{
Enabled = true,
},
ApplicationFeeAmount = 123,
TransferData = new PaymentIntentTransferDataOptions
{
Destination = "{{CONNECTED_ACCOUNT_ID}}", <- change this
},
};
var service = new PaymentIntentService();
service.Create(options);
We have a complex integration. We've been working on it for months, and this code has always worked up until the last 24h or so. I understand that in a simple implementation you can pass in an account ID, but we have a more involved situation than that.
We have made a new successful request:
req_DNPrkS1z5XYyyC
on test mode
sonic kestrel
This is using a different Connected Account so I don't see how this helps validate.
deft torrent
The crux of the issue is that this code works when we're using test connected accounts, but fails when we try to use a real one.
You mentioned we couldn't test outside of test mode. How can we verify a request against a real connected account that's connected to a real bank account?
sonic kestrel
You can make Test mode requests to live mode Connect Accounts
deft torrent
Ok, how can we do that?
Since we removed the duplication and it is working on Test, are we allowed to try this on live again?
sonic kestrel
Use your Test mode API keys with the live Connected Account.
You can make those requests on Connect Accounts that are only connected in Live mode to allow for better testing coverage
deft torrent
Ok, that will require some work on our end and we will do that.
In the interim, can we run this on Live and give you a new request ID?
sonic kestrel
I'm not sure what that will achieve. Are you going to create a new payment on the same Connect Account, a different one? What has changed?
deft torrent
We are in the process of setting up a test using the test mode API keys with a live connected account.
We have tried making a new payment on the same connected account without the duplicated parameters per your suggestion, and that works in test (200) and fails in live mode (500, same error).
sonic kestrel
We have tried making a new payment on the same connected account
Each of the requests you have provided me have had different connected accounts. Unless I am missing something
deft torrent
req_CmxoAAmB0GFeDO
This is a test mode call to the live mode connected account, and it is working
req_t6nrUo6wUWYM4I
This is a live mode call to the same live connected account, and it is failing
"currency": "USD",
We noticed that we are using lowercase 'usd' in one call and uppercast USD in another - this is because we're testing through swagger and we just typed it differently.
We don't know if this is the source of the issue, but I doubt it given we've been doing this for months.
that's the only difference I can see between the two calls
(besides the amount, which is above 50 and so should work either way)
sonic kestrel
Yes I don't think the currency case would through anything off and the amount differences should be fine. I'm reaching out to my colleagues for a second pair of eyes since I have other people I'm helping here too.
deft torrent
We tried it with capital USD and that failed as well:
req_tSYImveukHB5QO
sonic kestrel
Yes I didn't think that would have any effect
We are still having trouble understanding why this is working in Test mode, but looking at the Connected Account being used, they do not have the card_payments capability. So a first remediation step would be to request that for this Connect Account.
https://docs.stripe.com/api/accounts/update#update_account-capabilities-card_payments
deft torrent
We do not want the connected accounts to have the card_payments capability
sonic kestrel
Then you can't set them as the merchant of record.
deft torrent
I believe the documentation says otherwise, but we will test that now.
While we verify this, the merchant of record is correctly set in Test Mode, without the card_payments capability.
sonic kestrel
That part is the part that is not behaving as we expect
I do find the following message in the logs of the Test payment
user_error_message="You cannot create a charge with the `on_behalf_of` parameter set to a connected account with `transfers` but without the `card_payments` capability enabled."
so I'm not sure why we let this succeed when we already know it is invalid.
deft torrent
We have updated the capabilities on the account and we're waiting for Stripe to approve it
sonic kestrel
This may require additional verification requirements for the Connet Account
So I would keep an eye out for the account.updated webhook event
sonic kestrel
yes that Connect Account has the card_payments capability enabled so you won't hit the validation error I posted above.
We will raise the bug about Test mode internally since we don't want users to think that flow will work
Clearly it would have saved you some time if you had known it wasn't possible to use that flow earlier.
deft torrent
Thank you for the support - I'm glad we could help find a bug in Stripe hah
The error message also needs to be updated
Since it's way off base
sonic kestrel
I'm happy we figured it out! And I'll be raising this internally. We can definitely fix that error message simply by passing the internal one I shared above to the API response. That would have cleared things up
wise estuaryBOT
deft torrent
When we actually try to do an authorize on a user's card, we're getting a status: "requires_payment_method"
{
"id": "pi_3PgWkZKj7W6BzSLX0yAM8giY",
"object": "payment_intent",
"last_payment_error": null,
"livemode": true,
"next_action": null,
"status": "requires_payment_method",
"amount": 100,
"amount_capturable": 0,
"amount_details": {
"tip": {
}
},
"amount_received": 0,
"application": null,
"application_fee_amount": null,
"automatic_payment_methods": {
"allow_redirects": "always",
"enabled": true
},
"canceled_at": null,
"cancellation_reason": null,
"capture_method": "manual",
"client_secret": "pi_3PgWkZKj7W6BzSLX0yAM8giY_secret_vZUp1WMUyPltJL1XueTtL5u20",
"confirmation_method": "automatic",
"created": 1721933451,
"currency": "usd",
"customer": "cus_QXW2u713eDhrBN",
"description": "Test",
"invoice": null,
"latest_charge": null,
"metadata": {
},
"on_behalf_of": "acct_1PgC8VQTJgqnqveS",
"payment_method": null,
"payment_method_configuration_details": {
"id": "pmc_1PgUaIQTJgqnqveSSJ48HCyX",
"parent": "pmc_1PgUa9Kj7W6BzSLXorJmU8pt"
},
"payment_method_options": {
"card": {
"installments": null,
"mandate_options": null,
"network": null,
"request_three_d_secure": "automatic"
}
},
"payment_method_types": [
"card"
],
"processing": null,
"receipt_email": null,
"review": null,
"setup_future_usage": null,
"shipping": null,
"source": null,
"statement_descriptor": null,
"statement_descriptor_suffix": null,
"transfer_data": {
"destination": "acct_1PgC8VQTJgqnqveS"
},
"transfer_group": null
}
So, some part of the changes we made to remove the payment method don't seem to be working
orchid edge
I see that payment intent as being requires_confirmation -- how did you get that object/response?
deft torrent
How can I best answer that question? The code we're using?
orchid edge
Yea, where did that response come from? An API call?
deft torrent
yes
var options = new PaymentIntentCreateOptions
{
Amount = Convert.ToInt64(paymentRequest.Amount * 100),
Currency = paymentRequest.Currency,
TransferData = new PaymentIntentTransferDataOptions
{
Destination = developerAccount.StripeAccountId
},
OnBehalfOf = developerAccount.StripeAccountId,
PaymentMethod = paymentMethod.StripePaymentMethodId,
Customer = stripeUser.StripeCustomerId,
Description = paymentRequest.PaymentDescription,
CaptureMethod = "manual",
};
await LogPaymentEvent(options, traceId);
paymentIntent = await _paymentIntentService.CreateAsync(options);
orchid edge
I don't understand how you get that as requires_payment_method given the request I see above
Can you perform another request like this?
orchid edge
Yes, that response is similarly requires_confirmation
Which you should be able to see in your Dashboard logs: https://dashboard.stripe.com/logs/req_sVFuiDjRGS6OJ0
deft torrent
Yes, we see that, but we don't know why it is occurring
When we get the payment_intent.created, it says requires_payment_method, but you can see that we're passing it in:
"id": "pi_3PgX7oKj7W6BzSLX05ewbT0h",
"object": "payment_intent",
"last_payment_error": null,
"livemode": true,
"next_action": null,
"status": "requires_payment_method",
"amount": 100,
"amount_capturable": 0,
"amount_details": {
"tip": {
}
},
orchid edge
Oh, interesting, i do see the same in the event 🤔
But the response you get back from the creation request shows the latest status, correct? (Not the event)
orchid edge
When you call paymentIntent = await _paymentIntentService.CreateAsync(options); I would expect that the resulting paymentIntent has the status reflected in the response to your request
ie, paymentIntent.status is requires_confirmation
deft torrent
We haven't been checking for that status explicitly, we are updating the code for that.
In the interim, we tried to actually capture the $1.00 from this test and we got the below error. The previous support we received told us to remove the automatic_payment_methods fields because we were passing in a payment method directly.
A return_url must be specified because this Payment Intent is configured to automatically accept the payment methods enabled in the Dashboard, some of which may require a full page redirect to succeed. If you do not want to accept redirect-based payment methods, set automatic_payment_methods[enabled] to true and automatic_payment_methods[allow_redirects] to never when creating Setup Intents and Payment Intents.",
orchid edge
You can't capture until you confirm first
orchid edge
If you already have the payment method collected (as seen by you providing it during creation) you can try including confirm=true
The examples you've shared are not calling /confirm or /create with confirm=true
orchid edge
But it is failing
Can you share an example of the error you're referring to?
deft torrent
one momen
one moment
The error I shared above is the one we get back when we do the confirmation.
{
"error": {
"message": "A return_url must be specified because this Payment Intent is configured to automatically accept the payment methods enabled in the Dashboard, some of which may require a full page redirect to succeed. If you do not want to accept redirect-based payment methods, set automatic_payment_methods[enabled] to true and automatic_payment_methods[allow_redirects] to never when creating Setup Intents and Payment Intents.",
"payment_intent": {
"id": "pi_3PgWkZKj7W6BzSLX0yAM8giY",
"object": "payment_intent",
"amount": 100,
"amount_capturable": 0,
"amount_details": {
"tip": {
}
},
"amount_received": 0,
"application": null,
"application_fee_amount": null,
"automatic_payment_methods": {
"allow_redirects": "always",
"enabled": true
},
"canceled_at": null,
"cancellation_reason": null,
"capture_method": "manual",
"client_secret": "pi_3P*************************************************5u20",
"confirmation_method": "automatic",
"created": 1721933451,
"currency": "usd",
"customer": "cus_QXW2u713eDhrBN",
"description": "Test",
"invoice": null,
"last_payment_error": null,
"latest_charge": null,
"livemode": true,
"metadata": {
},
"next_action": null,
"on_behalf_of": "acct_1PgC8VQTJgqnqveS",
"payment_method": "pm_1PgWixKj7W6BzSLXym0goZU1",
"payment_method_configuration_details": {
"id": "pmc_1PgUaIQTJgqnqveSSJ48HCyX",
"parent": "pmc_1PgUa9Kj7W6BzSLXorJmU8pt"
},
"payment_method_options": {
"card": {
"installments": null,
"mandate_options": null,
"network": null,
"request_three_d_secure": "automatic"
}
},
"payment_method_types": [
"card"
],
"processing": null,
"receipt_email": null,
"review": null,
"setup_future_usage": null,
"shipping": null,
"source": null,
"statement_descriptor": null,
"statement_descriptor_suffix": null,
"status": "requires_confirmation",
"transfer_data": {
"destination": "acct_1PgC8VQTJgqnqveS"
},
"transfer_group": null
},
"request_log_url": "https://dashboard.stripe.com/logs/req_NgDxhzXSHp9ofM?t=1721935748",
"type": "invalid_request_error"
}
}
orchid edge
Yep, that error explains wht you need to do here though, right?
This related to an API change from last year: https://docs.stripe.com/upgrades#2023-08-16
If you do not want to accept redirect-based payment methods, set automatic_payment_methods[enabled] to true and automatic_payment_methods[allow_redirects] to never
deft torrent
I'm afraid not. We were originally specifying both the automatic_payment_methods and the specific payment method that we want to charge. The previous support engineer told us that we should not do that, which got us past the previous error we were encountering (which is a new Stripe change, this code has been working for us for months), but now we are receiving this error and have no clear resolution.
orchid edge
You need to add automatic_payment_methods[allow_redirects]=never
wise estuaryBOT
deft torrent
Ok, this goes against what Snufkin told us, but we will try it.
Ok, this failed:
Missing required param: automatic_payment_methods[enabled].
So is the goal to pass in automatic_payment_methods[enabled] = False, allow_redirects = never, and then also pass in the payment_method?
wintry pine
Hi, stepping in and let me catch up.
deft torrent
Hello
wintry pine
Ok, there seems to be different errors you're referring to. Can you confirm that you're still trying to get an answer why you're getting No valid payment method types for this Payment Intent. Please ensure that you have activated payment methods compatible with your chosen currency in your dashboard (https://dashboard.stripe.com/settings/payment_methods) or specify payment_method_types error? Or, something else?
deft torrent
The resolution to that error was to remove automatic_payment_methods.
After we removed automatic_payment_methods, we were then getting the redirect_url error.
We followed synthrider's instructions to set automatic_payment_methods[allow_redirects]=never
That fails because it cannot be set if automatic_payment_methods is disabled.
You can see every permutation of these errors in the following requests:
req_LZ3rsl6whld1uc
req_6EZpoQTK57v249
req_yNgOXFB2Cl8VW2
wintry pine
From further looking, it looks like this is related to capabilities. On this capability.updated event, evt_1PgWTOQTJgqnqveS46BreMqz you enabled card capabiities for the connected account at 2024-07-25 18:33:06 UTC, https://docs.stripe.com/api/accounts/update#update_account-capabilities. However, this request req_XGIm89t2jPnJpQ was made at
2024-07-25 16:26:45 UTC before the capability was added on the accounts.
Can you try making this request, req_XGIm89t2jPnJpQ now?
deft torrent
ok, let's try
As we wait for this update to deploy, I want to call out that we have tried this on Test and it failed, with the correct capabilities.
But we will try with Test API credentials against the live connected account
deft torrent
The engineer who made that particular request has signed off for the evening. Here is where are now:
We were able to make this request successfully: req_nPzAJpOf4zsBYM
However, the status is requires_confirmation:
"status": "requires_confirmation",
For the payment intent itself (pi_3PgYKuKj7W6BzSLX19f410fd)
it shows "status": "requires_payment_method",
So the status is Incomplete
wise estuaryBOT
wintry pine
That is great to hear!
Form that request id you shared, it looks like it was confirmed and the payment intent succeeded: pi_3PgYKuKj7W6BzSLX19f410fd.
Can you review this again?
you confirmed it here: req_ObwPUPx96k2HMe
deft torrent
It did successfully hit the credit card, but it is showing up as Incomplete in Stripe's dashboard.
wintry pine
and then captured it here, req_hxCuPiZOjW3qJg
wintry pine
That looks like a different payment intent
deft torrent
let me investigate
We just tried it again and now the status is Uncaptured, which is what we're expecting. We're going to try charging it through all the way.
A separate question while we wait for this to go through, the description we're passing in is "Test", but this is showing up on my CC statement as "PAY-I.COM".
How do we change the statement descriptor?
wintry pine
The description and the statement descriptor are two separate concepts.
The description is what you want to add on the Payment Intent objects itself adding useful information for you. The statement descriptor is what is shown on your customer's bank statements. You can read more about it here, https://docs.stripe.com/get-started/account/statement-descriptors.
wintry pine
Whohoo!
wintry pine
Sure, sorry we could not unblock you faster.