#sinotz-charge

1 messages · Page 1 of 1 (latest)

wild verge
#

hello! so Charges still exist in the API, PaymentIntents create Charges under the hood still but mostly you don't interact with the Charge object yourself

the PaymentIntent is the abstraction you usually need to interact with

#

with that said, what was your real question?

stark owl
#

ok well I am looking to make this sigma query from years ago into a python only script to get new sales https://dpaste.org/LgXN

wild verge
#

yeah in that case it would be fine to list Charges, a Charge still represents "a payment".

stark owl
#

ok cool thanks. I have a lot of queries I want to translate into python

#

so how would i get payment intents/charges with a status of succeeded?

swift mountain
#

👋 I'm taking over since @wild verge has to head out soon

stark owl
#

k

swift mountain
#

You just want to be able to retrieve all the payment intents/charges that are succeeded through the API, right?

stark owl
#

yup

swift mountain
stark owl
#

ok should I use auto_paging_iter() right off the bat in the list?

#

stripe.PaymentIntent.list().auto_paging_iter() ?

swift mountain
#

Yup, if you want to use auto-pagination you would use that right from the start

stark owl
#

ok cool

#

<generator object ListObject.auto_paging_iter at 0x7f53ed2feb30

#

if i loop through it, it is fine though

#

it has been a while since i used stripe code lol

#

so if i wanted to do in between date x and date y how would i do that?

swift mountain
stark owl
#

ok and what is ended_at ?

#

ending_before

#

oh starting at this record?

swift mountain
#

Yeah ending_before is if you want to do the pagination yourself

stark owl
#

This does not seem to work stripe.PaymentIntent.list(created.gte="1638815734",created.lte="1638815734")

swift mountain
#

What about it isn't working?

stark owl
#

it thinks i am assigning the epoch numbers to the created variable

swift mountain
#

Sorry let me be specific - what is the error message you're seeing?

stark owl
#

SyntaxError: expression cannot contain assignment, perhaps you meant "=="?

#

== does not work either

swift mountain
#

This is with python right?

stark owl
#

yes

#

api says dictionary maybe that is why

#

{created.gte:"1638815734"},{created.lte="1638815734"}

swift mountain
#

Yeah it has to be a dictionary, so you'd want something like

    created={
        "lte": "1638815734",
        "gte": "1638815734",
    },
stark owl
#

cool that worked ty

#

hmm i see something strange in my dashboard. Any idea why a successful daily subscription sometimes charges twice on the same day?

#

and at different times too

swift mountain
#

Do you have a subscription ID I can take a look at?

stark owl
#

sub_Iyi2o7Hji1va7D

#

oh that subscription makes sense but on here it looks differen

swift mountain
#

Gotcha - so what specifically on the customer page is confusing you?

stark owl
#

i see 2 december 4 charges and 2 december 1 charges

#

i didn't make any changes to the account either i just let the subscription ride

#

perhaps i found a bug or this is just the way stripe handles it where it chooses the best time to add it?

swift mountain
#

I don't think it's a bug per se - it's just weirdness with timezones. The Payments list on the customer is based on when the Payment Intent is created, while the list on the Subscription page is when the Invoice was created.

stark owl
#

oh ok ty

#

makes me feel better now

#

because that may mean i have to change this python code to the right timezone

#

correct me if i am wrong but EST is 4 hours behind UTC?

#

or GMT?

#

how would I do that in python created epoch time into EST

swift mountain
#

Actually, time zone may have been the wrong phrase to use there 🤦‍♂️

stark owl
#

ok well it would still be nice to get the right amount for my timezone. But otherwise what did you mean instead?

swift mountain
#

GIve me one minute to type this out

stark owl
#

sure

swift mountain
#

Okay so there's a few things at play here - as I said earlier, the subs page is listed out by Invoice creation (which has the daily cadence you're expecting). The Customer page lists by Payment Intent creation which can vary, since it's happening automatically on our end approximately an hour after the invoice is created. The issue here is that sometimes the Payment Intent creation gets slightly delayed by an additional hour or two.

stark owl
#

ok makes sense

swift mountain
#

Because your Invoices are regularly created later in the day (around 9PM for that timezone), the Payment Intent is usually created around 10PM the same day, but if it's delayed it can sometimes just barely pass into the next day

stark owl
#

ok so i am wondering for bookkeeping purposes which object should i track for successful payments between which dates?

#

successful invoices not payment intents?

swift mountain
#

Well what specifically are you using these bookkeeping records for? If you want to know what billing period were successfully paid for then you'd want the Invoice since it has details on the billing period

stark owl
#

basically i want to get a bunch of metrics - monthly/yearly total successful payment amounts, total cancels, total refunds, total disputes, etc.

#

but if i want just all brand new sales/charges i would use charges/payment intents?

swift mountain
#

If you're purely looking at payment behavior then yes, I'd just look at the charges/payment intents

stark owl
#

ok but to be safe use the invoice object though?

#

i might be able to get new sales with that too by doing first time invoice paid for the customer

swift mountain
#

Really what matters here is the kind of metrics you're looking to display - you know best what kind of information you need, and either will work for signalling payment success so choose whichever works best for you

#

I need to head out by @ashen axle can help with any follow-up questions!