Hi Siva,

Thanks for the detailed request — a couple of things worth clarifying before we scope this.

First, the field you referenced as also existing on the PaymentIntent object is actually a different, related field. PaymentIntent.payment_method_options.card holds configuration you set before a payment is processed (e.g., whether to request 3D Secure, installment options). Charge.payment_method_details.card holds the outcome of the transaction after it's processed (brand, last4, 3D Secure result, and network_transaction_id). network_transaction_id only exists on the Charge side. Are you also interested in the configuration data set before a payment is processed (what's available on the PaymentIntent object)?

Second: the network_transaction_id data should already exist in your Fivetran-synced data today. We land the full payment_method_details object from Stripe's Charge response in the charge_payment_method_details table, keyed by charge_id and payment_method_type. For card transactions, the value column contains the entire nested card object from Stripe, including network_transaction_id, whenever Stripe's response includes it for that transaction. You can query it today, e.g.:

SELECT charge_id, value:network_transaction_id
FROM charge_payment_method_details
WHERE payment_method_type = 'card'

(exact JSON-extraction syntax depends on your warehouse).

What we don't do today is break that JSON blob into individual dedicated columns or a separate table. network_transaction_id and its neighboring fields (brand, last4, 3D Secure result, wallet, etc.) all live inside that one value column.

Please check to see if you can already access the network_transaction_id data and let me know if it would still be valuable to have us break that data out into columns or a table for easier querying.

Best,

Sadie Martin

Product Manager