airbytehq / airbyte

The leading data integration platform for ETL / ELT data pipelines from APIs, databases & files to data warehouses, data lakes & data lakehouses. Both self-hosted and Cloud-hosted.
https://airbyte.com
Other
15.77k stars 4.04k forks source link

[source-stripe] does not sync unsuccessful payment methods #39375

Open hellmund opened 3 months ago

hellmund commented 3 months ago

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, whose PaymentMethods are eventually attached to Customers, 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 the payment_methods stream, which are attached to a customer. So, running a full analysis on the failed setup_intents and their corresponding failed setup_attempts is not possible, as the related payment_methods are missing in the stream.

The suggestion is, to include in the payment_methods stream not only those that are attached to customers, but also those from each setup_attempt.

Steps to reproduce:

Expected behavior:

Actual behavior:

Relevant log output

No response

Contribute

marcosmarxm commented 3 months ago

@airbytehq/critical-connectors can take a look in this issue?

bazarnov commented 3 months ago

@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

maxi297 commented 3 months ago

@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

hellmund commented 3 months ago

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.

maxi297 commented 3 months ago

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:

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?

maxi297 commented 3 months ago

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

hellmund commented 3 months ago

@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.

maxi297 commented 2 months ago

@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.

hellmund commented 2 months ago

@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.