#neha_paymentintent-dataingestion
glacial hearthBOT
đ 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/1233521067662905486
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
hard sparrowBOT
wraith quartz
neha_paymentintent-dataingestion
@kindred copper what we recommend is using the List PaymentIntents API, pass limit: 100 and ingest them one page at a time
kindred copper
default order is created_at?
wraith quartz
yeah most recently created first
kindred copper
oh so... by the time i'm done, there might be more payments on the first page?
wraith quartz
yes which is fine, you can run a second list and stop at the first PaymentIntent you recognize!
The idea is usually you build the webhook part first, and then you backfill
kindred copper
right, makes sense
follow-up:
i have 2 types of products: subscription & one-off purchase
i want to somehow distinguish between the two via this new table i'm making
priceId would work, but it sounds like i'd have to do a JOIN on the Invoice using the paymentIntent.invoice
wraith quartz
yep
PaymentIntents can point to an Invoice and a Subscription and you likely want multiple tables
kindred copper
i don't see subscription on the paymentIntent object
wraith quartz
yeah that's normal. PaymentIntent has invoice: 'in_123 and Invoice has subscription: 'sub_123'
kindred copper
which webhook do you recommend listening to? obviously interested in both payments & refunds
i don't see one where data is a payment intent
wraith quartz
There are a ton with PaymentIntent, they all start with payment_intent.
kindred copper
oh sorry, yes i do, i was control F-ing for one word instead of two
still there's....
"created" but no "refuned"
wraith quartz
charge.refunded
https://docs.stripe.com/payments-api/tour#payment-objects I recommend watching this to understand all the important objects
kindred copper
so charge.succeeded and charge.refunded would be sufficient?
or are you recommending payment_intent.suceeded + charge.refunded?
wraith quartz
the latter
wraith quartz
it's better to listen to PaymentIntents Events
wraith quartz
It's our newer API, it groups all Events under the same object, it's just the best way. Or listen to all and ingest all the data
kindred copper
ok so
goal: get total spend per customer over a certain time range
listen to payment_intent.succeded
go through underlying charges, add 1 row per charge (created_at | charge_id | customer_id | amount_captured | amount_refunded)
listen to charge.refunded
find entry in table (by id) and update amount_refunded field
secondary goal: distinguish recurring spend from one-off spend
it looks like "payment_intent.succeded" won't have an invoice if it's one-off? is that a hacky way to view it?
wraith quartz
it's not hacky, totally reasonable way to decide between one-off and recurring!
kindred copper
the rate limit for paginating through payment intents is 10 requests per second, correct? so with limit: 100, 10 * 100 = 1,000 rows per second?
and if i want/need to dig into
payment intent => invoice => subscription id
and therefore have to make an extra call
api.retrieve(invoiceId)
how does that affect my rate limit? because presumably i'd need to do this once per row, so 100 times per payment intent batch
wraith quartz
Rate limits docs: https://docs.stripe.com/rate-limits
=> 100 requests per second
Avoiding making multiple requests can be done with our Expansion feature. More details in https://stripe.com/docs/expand and our video: https://www.youtube.com/watch?v=m8Vj_CEWyQc