#MacHacker-checkout-proration-behavior

1 messages · Page 1 of 1 (latest)

vapid iron
slender karma
#

Hi. Looking into this now

icy shadow
#

I might have just found it, not sure why it was giving me an error last time but let me know what you find because I'm still trying to make sure it is actually working lol

slender karma
#

What are you setting?

#

I don't believe it's possible to set proration_behavior through Checkout actually. Double checking now though

icy shadow
#

That's what I was afraid of 😬

#

I was trying to set it in the base level

#

of the payload

slender karma
#

You could always take the route of using Elements

#

That with the Subscriptions API would allow you to use the proration_behavior parameter

icy shadow
#

lol, had to do that for my last client too 😂

#

Would there be any way to catch it with a webhook and update it before the charge goes through?

#

We'll probably go with elements later down the road but for now we have other things to get to so we are trying to save some time

#

The reason we don't want it prorated is because they are donations we are accepting

slender karma
#

Yeah so I would recommend Elements for this

#

You won't be able to set it in Checkout unfortunately

icy shadow
#

Yeah I was able to test a little more thoroughly and can confirm there is nowhere it's accepted...

#

Thanks for the confirmation

slender karma
#

No problem

vapid iron
#

@icy shadow , are you seeing prorations on the first payment for subscriptions you create with a Checkout Session? IIRC the billing cycle anchor defaults to today for Checkout so if someone signed up today they would be charged the full amount on the 23rd of every month

icy shadow
#

That's what I assumed, but yes one of our donations got prorated by the looks of it which is why I started looking into it

#

@vapid iron

vapid iron
#

Interesting. Do you have the ID for that donation?

icy shadow
#

Sure let me look into it again, one second

#

here is the event id evt_1K2isYCwu0QaPl6AvQf6a2pU where I noticed -> "proration": true,

#

actually, you know what... I think I've been looking at this backwards

#

I think originally they had meant to make a one time donation, so they asked for the subscription to be canceled

#

and it's when we canceled the subscription that the prorated charge occurred?

#

here is the customer id cus_Kh5lEUgHeZGm6h (not sure if you have access to any of this on your side)

#

but I also see

#

I was originally looking at the events page

#

which is why I guess I didn't notice there were actually two invoices

#

ok by the looks of it, the first charge was not prorated and they weren't charged a second time

#

it looks as if it gave them "credit" for canceling early?

vapid iron
#

Yes, that is exactly what it looks like. The cancellation is what created the proration/gave them credit here.

icy shadow
#

Hoora! I was not looking forward to hacking elements together again 😂

#

Ok that's perfect, I was originally poking around because I'm setting up webhooks to send more customized emails since these are donations and not purchases and when I came across what looked like a charge for not the total amount I started looking into prorated charge logic before even checking the customer page lol

#

Thanks for your help @vapid iron and @slender karma

vapid iron
#

Yes, glad we could clear that up. It looks like that subscription was cancelled through the dashboard so in future I think they just have to specify "No Refund" when cancelling.

icy shadow
#

Perfect I was just going to ask about that

icy shadow
#

Just in case someone forgets?

#

Ah, just scrolled down in the link

vapid iron
#

I don't think it is on by default but yes you can set that up if you want.

#

Though also I don't know if that is something you'd want to automate here

icy shadow
#

I'll already be listening to the event to send out cancelation emails

#

Hmm, that's fair, just in case down the line we have a valid reason not to refund