Open hellmund opened 5 months ago
@airbytehq/critical-connectors can take a look in this issue?
@marcosmarxm We will take a look at it, and scope the work needs to be done here, thanks for poking @marcosmarxm and addressing the issue @hellmund
@bazarnov I think I can reproduce the issue on our side. However, querying for the ID specifically leads to this response:
{
"error": {
"code": "resource_missing",
"doc_url": "https://stripe.com/docs/error-codes/resource-missing",
"message": "No such PaymentMethod: '<id>'; It's possible this PaymentMethod exists on one of your connected accounts, in which case you should retry this request on that connected account. Learn more at https://stripe.com/docs/connect/authentication",
"param": "payment_method",
"request_log_url": "https://dashboard.stripe.com/test/logs/req_8AO3mdC6UyOACn?t=1718223794",
"type": "invalid_request_error"
}
}
I'll investigate more tomorrow and keep you posted
Hello! Wondering if there are any updates on this issue?
When spot-checking this in a production account, I am able to fetch the respective PaymentMethod manually via Stripe's REST API. @maxi297 your error description seems to hint that you might have a more complex setup, trying to use a payment method from a different account.
In my case - although it's a Stripe Connect project - I want to look at the "Stripe Platform account" where both, the SetupIntent and the respective payment method are located.
Thanks for responding on this @hellmund. This got deprioritized a bit recently but if you can provide more information to ease the investigation, we might be able to provide a more timely fix.
I am able to fetch the respective PaymentMethod manually via Stripe's REST API
What do you mean by that? On my side using our test environment, the repro steps are:
Get any setup intent
~% curl -X GET -H 'Authorization: Bearer <redacted client secret>' 'https://api.stripe.com/v1/setup_intents/seti_1KnfIcEcXtiJtvvh61qlCaDf'
{
"id": "seti_1KnfIcEcXtiJtvvh61qlCaDf",
"object": "setup_intent",
"application": null,
"automatic_payment_methods": null,
"cancellation_reason": null,
"client_secret": "seti_1KnfIcEcXtiJtvvh61qlCaDf_secret_LUebcbyw8V1e8Pxk3aAjzDXMOXdFMCe",
"created": 1649752930,
"customer": null,
"description": null,
"flow_directions": null,
"last_setup_error": null,
"latest_attempt": "setatt_1KnfIdEcXtiJtvvhpDrYVlRP",
"livemode": false,
"mandate": null,
"metadata": {},
"next_action": null,
"on_behalf_of": null,
"payment_method": "pm_1KnfIc2eZvKYlo2Civ7snSPy",
"payment_method_configuration_details": null,
"payment_method_options": {
"acss_debit": {
"currency": "cad",
"mandate_options": {
"interval_description": "First day of every month",
"payment_schedule": "interval",
"transaction_type": "personal"
},
"verification_method": "automatic"
}
},
"payment_method_types": [
"acss_debit"
],
"single_use_mandate": null,
"status": "succeeded",
"usage": "off_session"
}
Get the corresponding setup attempt
~% curl -X GET -H 'Authorization: Bearer <redacted client secret>' 'https://api.stripe.com/v1/setup_attempts?setup_intent=seti_1KnfIcEcXtiJtvvh61qlCaDf'
{
"object": "list",
"data": [
{
"id": "setatt_1KnfIdEcXtiJtvvhpDrYVlRP",
"object": "setup_attempt",
"application": null,
"created": 1649752931,
"customer": null,
"flow_directions": null,
"livemode": false,
"on_behalf_of": null,
"payment_method": "pm_1KnfIc2eZvKYlo2Civ7snSPy",
"payment_method_details": {
"acss_debit": {},
"type": "acss_debit"
},
"setup_error": null,
"setup_intent": "seti_1KnfIcEcXtiJtvvh61qlCaDf",
"status": "succeeded",
"usage": "off_session"
}
],
"has_more": false,
"url": "/v1/setup_attempts"
}
Get the payment method associated with the setup intent and attempt (both share the same payment_method
)
~% curl -X GET -H 'Authorization: Bearer <redacted client secret>' 'https://api.stripe.com/v1/payment_methods/pm_1KnfIc2eZvKYlo2Civ7snSPy'
{
"error": {
"code": "resource_missing",
"doc_url": "https://stripe.com/docs/error-codes/resource-missing",
"message": "No such PaymentMethod: 'pm_1KnfIc2eZvKYlo2Civ7snSPy'; It's possible this PaymentMethod exists on one of your connected accounts, in which case you should retry this request on that connected account. Learn more at https://stripe.com/docs/connect/authentication",
"param": "payment_method",
"request_log_url": "https://dashboard.stripe.com/test/logs/req_Fg6wBBHLSPhibY?t=1719943870",
"type": "invalid_request_error"
}
}
Expected outcome: Querying the payment method by ID with the same authentication method than in the setup intent/attempt should return a payment method object.
So it seems like the payment method is not always returned by the API. I'll reach out to Stripe support to get more information about that. In the meanwhile, can you confirm that those steps make sense to describe the issue you are facing and that you can reproduce them with the same outcome?
Update: Stripe support mentions that for our case, it is a bug on their side as to when those entries were created (around April 2022). I'll generate a new test case to confirm that it is solve when creating new data.
This means that confirming the repro steps provides the same result on your side is crucial. Can you share more information about this? If you are not comfortable sharing this information in this ticket, you can always send it to maxime@airbyte.io
@maxi297 sounds good. While I'm interested in the payment method referred in the SetupIntent object for my use case, a SetupIntent can have multiple SetupAttempts with potentially different payment methods. I guess fetching all payment methods of all SetupAttempts of each SetupIntent might be the more comprehensive approach.
@hellmund Can you expand on I guess fetching all payment methods of all SetupAttempts
? Currently, we fetch all payment methods independently of the SetupAttempts. Hence, my concern is that those are either deleted or not accessible through the API. For the case of our test environment today, Stripe confirms that this is a bug on their side. I would like to confirm in which case you case fall into by following the following steps. Without repro steps or a sample of API calls to describe the specifics of this ask, this will be hard to us to make sure we tackle the right issue.
@maxi297 sorry, my bad - I think there was a bit of a misunderstanding as I was wrongly looking only into the payment_methods
stream, which is even empty in my case, when I synchronize only recent setup_intents
and setup_attempts
.
I completely missed that the payment method of each successful and also failed attempt are in fact already included within the setup_attempts
stream in the field payment_method_details
- all good and that's exactly what I was looking for. Maybe would be good to clarify in the documentation, for which cases entries will appear in the payment_methods
stream. Thanks.
Connector Name
source-stripe
Connector Version
5.3.9
What step the error happened?
During the sync
Relevant information
First of all - thank you for building this amazing connector! It's great to be able to dig into Stripe raw data and go into different levels of detail!
While I get good information about successful
SetupIntents
, whosePaymentMethods
are eventually attached toCustomers
, it would be great to also receive all PaymentMethods related to a SetupAttempt in the payment_methods stream, including those where the SetupAttempt was unsuccessful. Currently, the connector seems to only include entries in thepayment_methods
stream, which are attached to acustomer
. So, running a full analysis on the failedsetup_intents
and their corresponding failedsetup_attempts
is not possible, as the relatedpayment_methods
are missing in the stream.The suggestion is, to include in the
payment_methods
stream not only those that are attached tocustomers
, but also those from eachsetup_attempt
.Steps to reproduce:
payment_methods
,setup_attempts
andsetup_intents
to be included in the syncpayment_methods
tableExpected behavior:
payment_methods
includes all payment methods from the sync'edsetup_attempts
Actual behavior:
payment_methods
is emptyRelevant log output
No response
Contribute