#Ken Wong

1 messages · Page 1 of 1 (latest)

junior gulch
#

Ken Wong

#

Do you have an example of a payment intent/charge that you are not able to see from your partner?

worthy slate
#

yes. should i post that charge id here?

junior gulch
#

yup!

#

It would also be helpful if you could share one of yours that you're able to see without a problem

worthy slate
#

oh definitely!

#

cannot see: ch_3Jstt8ATJTe4UrFz2OjB11ff

#

can see: ch_3Jr4AwATJTe4UrFz2rEU5rHl

#

we have different keys... our company, partner company and our company bulk pull ID

#

we're using the bulk pull ID to bring back data and we were thinking this should also bring back our partner company data because our client gave us the keys

#

and our partner sends that same charge key to our system after a transaction completes through stripe, so i'm just trying to reconcile Stripe as the source of truth for all Stripe processed transactions with all payments we post to our customer in our system when we run billing.

#

unfortunately, we see some transactions we didn't log that our system customer portal did, so we're fixing that. the bulk pull is definitely helping us quantify and repair our problems. so we don't know why we can't see our partner company's transactions for our client because all payments are kept in our software to bill customers and then a receipt for payments made by any channel they made a payment in

junior gulch
#

When you say you "cannot see" them - is this through Stripe's dashboard? Or some other UI that is managed by you?

worthy slate
#

my apologies.. it's through the API

#

i'm doing the bulk data pull through the API for all payment intents created, so i can compare the charges we store to see if we miss any items.

hidden lotus
worthy slate
#

i called this API end point by timeframe:

#

you can excuse my variable.

#

i use this endpoint to pull data in batches of 100 from the last date we have in our reporting table to do the check on our side.

hidden lotus
#

that seems unrelated, that's about PaymentIntent

#

The Charge you can't find was never created on a PaymentIntent so it's expected

#

@worthy slate does that make sense?

worthy slate
#

hmm.. all payment intents have a charge json msg nested inside of it... so i downloaded all the payment intents, then looped through all the charge data to reconstruct it to a table.

#

can i retrieve only the charges the same way i'm retrieving the payment intents in bulk?

#

i looked at your link page, it doesn't seem like i can use a date range parameter to paginate through

#

i take that back. i was looking at the list charges, so i can retrieve it that way... so why the concept of paymentintent if a charge is sufficient?

#

our partner vendor is doing charges only, i guess?

hidden lotus
#

Sorry there's a lot you might not know/understand here

#

a PaymentIntent represent the state machine of attempting payments. So a PaymentIntent gets confirmed which creates a Charge. And it can create more than once charge if it keeps being declined (though only one successful)

#

But PaymentIntents shipped in 2018, before that we only had charges. The charge you can't find was created directly via the legacy Charge API without a PaymentIntent

worthy slate
#

ahh, i see!

#

that explains it

#

our partner is probably using a code written years ago

#

so if i pulled from the charge list, it will also include charges created from paymentintents?

hidden lotus
#

correct!

worthy slate
#

Thanks. I think you answered my questions! very helpful. i also am pulling from the charges endpoint and will hopefully find what i need.

#

how do i know which key each charge came frome?

remote elm
#

Hello @worthy slate I will take over from here

worthy slate
#

hey! thanks.

remote elm
#

What do you mean by "key"?

worthy slate
#

key = api secret key

remote elm
#

One API Secret Key tight to one Stripe Account. All Charges you are seeing should come from a same Stripe Account

worthy slate
#

our client gave out 3 keys... 1 to our partner, two 2 us.

#

for us, we have one for production use and one for bulk pull.

#

the bulk is done periodically to allow us to compare and repair our work if something looked faulty

remote elm
#

The bulk pull key and the production key, how do they looks like in the start? All are sk_live_xxx ?

worthy slate
#

yes.

#

the production key we use is for our live system. we asked our client for another key so we don't comingle calls and can shut down anything outside our main app if needed. so we call it our bulk api key for the purpose of bringing back data and anything that is essentially read-only from stripe

#

our application has no reconciliation functions, so something had to be built outside to compare what it didn't write for whatever reason to our database to include in our next bill to our client's customers.

remote elm
#

Okie I see. So those 2 keys should be from the same account