Hi - We started using this integration with Stitch and are finding seemingly random rows of data missing from our destinations after Stitch processes and unsure where to look for the issue. Is there a way to view errors or process manual records?

Request to add merchant_account_id to schema so you can see the different accounts.

Here is a reference to Braintree's transaction schema.

Braintree's API does not support using updated_at as a search parameter for retrieving records and requesting records based on updated_at returns the following error:

2017-11-06 14:52:04,053Z tap - AttributeError: type object 'TransactionSearch' has no attribute 'updated_at'

tap-braintree currently requests records based on created_at, so updates made in the source are not captured by the tap.

This could be mitigated by requesting all transactions, then storing a STATE based on the updated_at attribute returned for transactions and emitting only the records that meet or exceed that STATE.

Hey everyone,

On the Braintree integration on Stitch this tap sometimes fails with:

('Connection broken: IncompleteRead(0 bytes read)', IncompleteRead(0 bytes read))

I've also recently noticed that some transactions on Braintree are not being pushed to my destination on Stitch. Looking at the extraction logs it seems like the amount of records fetched by the tap does not match the amount of transactions I get when I query the same time range in Braintree.

For example, I get:
2020-02-25 14:35:45,367Z tap - INFO transactions: Fetched 5319 records from 2020-01-31 00:00:00+00:00 - 2020-02-01 00:00:00+00:00
But Braintree returns 5490 transactions in the same time period.

Can anyone shed light into this, and are the two issues related?

Thanks

Our ETL process is taking about 5 hours to run (and we're lucky if we go a day without any errors), and it's running every 6 hours. If we were able to make use of an attribution window things would run a whole lot faster

At the moment, it appears that PayPal details are in transactions.json whereas it should be in paypal_details.json (per https://docs.google.com/presentation/d/1Zys1u4_X81BLNL4JoJIJbdbWY68c15tFCTsnmvLoiTw/edit#slide=id.p), which doesn't even exist.

Also, the subscription model seems to be missing.

I'm sure others would greatly appreciate if these were extracted. If it's as simple as editing the json file, I would be more than willing to own this task!

Hey!

I'm using the Braintree tap within Stitch to replicate data to Google BigQuery.

Right now, almost no orders are being updated with the disbursement date or status. This seems to be because the updated_at field which is used to filter out records that haven't changed isn't changed when the disbursement date is.

For instance, here are a few records:

You'll see that the disbursement_date is always greater than the updated_at value, so the record is never updated.

I'm trying to get a call with Braintree technical support to see if this is a problem with their API, as this doesn't seem like correct behavior - but I wonder if they treat disbursement differently. I'm also not optimistic about getting an update to the API quickly, and my client needs this data for reconciliation and invoicing their supplier for inventory (in other words - very urgently).

However, I was thinking a workaround within the tap could be to compare latest_updated_at to the greater of either updated_at or disbursement_date. That way, updates to disbursement_date would be included, but it would still compare to updated_at if that was more recent.

I'm happy to do a fork and try to test out a solution but I wanted to check whether it made sense or whether anyone else has seen a similar issue and found a workaround.

Thanks!

Add a .circleci/config.yml file that runs pylint. See https://github.com/singer-io/tap-zendesk. Basically want a base ubuntu:16.04 image that does nothing but run our standard config of pylint.

disbursement_details__disbursement_date is being saved to redshift as a varchar. Other dates seem to be stored correctly, so maybe I introduced an error when adding disbursement date?

\d braintree.transactions 
                          Table "braintree.transactions"
                 Column                  |            Type             | Modifiers 
-----------------------------------------+-----------------------------+-----------
 _sdc_batched_at                         | timestamp without time zone | 
 _sdc_received_at                        | timestamp without time zone | 
 _sdc_sequence                           | bigint                      | 
 _sdc_table_version                      | bigint                      | 
 amount                                  | double precision            | 
 created_at                              | timestamp without time zone | 
 credit_card_details__customer_location  | character varying(128)      | 
 currency_iso_code                       | character varying(128)      | 
 customer_details__id                    | character varying(128)      | 
 id                                      | character varying(128)      | 
 order_id                                | character varying(128)      | 
 processor_authorization_code            | character varying(128)      | 
 processor_response_code                 | character varying(128)      | 
 processor_response_text                 | character varying(128)      | 
 status                                  | character varying(128)      | 
 type                                    | character varying(128)      | 
 updated_at                              | timestamp without time zone | 
 gateway_rejection_reason                | character varying(128)      | 
 refunded_transaction_id                 | character varying(128)      | 
 customer_details__email                 | character varying(128)      | 
 settlement_batch_id                     | character varying(128)      | 
 disbursement_details__disbursement_date | character varying(128)      | 
 disbursement_details__success           | boolean                     | 

The schema specification:

"disbursement_date": {
  "anyOf": [
    {
      "type": "string",
      "format": "date-time"
    },
    {
      "type": "null"
    }
  ]
},

This seems to match that of updated_at without the allowance for null.

"updated_at": {
  "type": "string",
  "format": "date-time"
},

According to communications from Paypal, they may stop supporting the version currently used here at the end of February:

A new version of the SDK was released on October 14, 2022, with new security enhancements. Please upgrade to the Braintree Python SDK v.4.17.1 or higher as soon as possible. Starting February 28, 2023, older versions of the SDK may no longer be supported.

To make this update:
If you're currently using v4 of the Python SDK, you need to upgrade the SDK to v4.17.1 or higher. Your integration will not require any other changes.
If you're currently using v3 or lower of the Braintree Python SDK, please upgrade to Braintree Python SDK v3.59.1. You also should plan to upgrade to v4.17.1 or higher in the near future. See our migration guide for details on necessary integration changes.
Should this remediation require an update to your integration, you may need to engage a developer or speak to your shopping cart or third-party provider.

For any questions, please don’t hesitate to contact Braintree Support for assistance.

It looks like the integration hasn't been storing a STATE value to use as a bookmark to start the next extraction job on a recent base load I started. Each extraction has been starting again from the historical start-date I configured.

The result is that my transaction data only populates up until January of 2017, but will continue to run 6-hour limited extractions on past replicated data.

To solve for this, I just reset my start date to later than the max updated_at field value. Let me know if I need to expound on this particular issue.

Motivation

We, as well as others, utilize braintree custom fields on our transactions [1] and we would like to be able to sync these to our database.

Design Considerations

The custom fields return as a string, so they can easily be stored into a custom_fields TEXT column. The hope is that this would be a simple PR just editing the schema, but I would first like to see if this would be a change which y'all are willing to accept and if there are any potential issues which you may see.

Either I or someone else at Packlane would be more than willing to make this PR and see it through the entire process.

[1] https://developers.braintreepayments.com/reference/request/transaction/sale/python#custom-fields

There are two foreign keys in the transactions table for a given merchant account: customer_id and subscription_id.

subscription_id is not currently present in the schema of this tap, but is essential for business logic when reconciling, for example, payment data for multiple subscriptions to a single user, or monthly payments under a single subscription.

A full schema for the transactions table is documented here.