#rayrayy-cancel-period-end

1 messages ยท Page 1 of 1 (latest)

waxen cargo
#

Hi there!

#

Can you provide the request ID and the code you are using to update the Sub?

white tulip
#

the update subscription method is a simple put on /stripe/subscription/:subscriptionId
reqId is req_BHncvMMtAZCOM2
Thanks!

waxen cargo
#

Will you do me a favor and re-save your code again and run another test here? There isn't really a good reason we wouldn't receive/see the parameter if it is being passed.

#

Possibly some sort of caching issue? Though that doesn't make a lot of sense to me either...

white tulip
#

lol, yea prbs not caching, it should at least show in post body ๐Ÿ˜…

waxen cargo
#

Right it would show in post body if it was making it to us

#

I'm saying caching on your side of sending us the past data

#

I'll test as well just to make sure it works for me

#

Yep works fine for me

white tulip
#

Can ya send ur payload plz ?

waxen cargo
#
    'sub_1LZhMIBpF9kEgTScuUXPxP7b',
    {
      payment_behavior: 'error_if_incomplete',
      proration_behavior: 'always_invoice',
      cancel_at_period_end: true,
    },```
#

you may want to check on this.paymentService.updateSubscription?

#

I assume that is wrapping stripe.subscriptions.update?

#

Ah let me check on one thing

#

You are on an older version of the Node SDK

white tulip
#

Nope we are using stripe api directly

waxen cargo
#

Ah interesting.

white tulip
#

it's also on test mode, but I dont think that should make a difference

waxen cargo
#

Mine is test as well, and yeah should not make any difference

#

Can you log out the subscription ID you updated and test again?

white tulip
#

subscription id: sub_1LaKJUGjQawimwZR9E3cenD3
reqId: req_1Esfk80cI8AVR5
Same problem ๐Ÿ˜ข

#

it could be that something is filtiring this out, can i cancel_at_period_end if subscription is on a schedule ?

waxen cargo
#

Ah good question

#

I thought so but that could throw a wrench in things

#

That sub isn't on a schedule though, no?

white tulip
#

I tried sending cancel_at instead same issue, I am not sure if its on scheculde how do i check ?

waxen cargo
#

Well there would be an event about adding a schedule. And I can see internally there is no schedule related to that Sub

white tulip
#

let me try connecting directly to this and see what happens, with the sdk

waxen cargo
#

Good idea

white tulip
#

wierd works via sdk

#

Any idea why this could be happening ?

#

could it be maybe because of api version ?

waxen cargo
#

I'm really not sure. Let me ask a teammate

#

Can you provide request ID for the request that did work with SDK?

white tulip
#

ofc bro one sec

#

req_WEXtq1L717z7sk

waxen cargo
#

What is ${moralisPaymentServerURL}... I just realized I don't actually think you are hitting our API directly

#

I think you are instead hitting your own server and then hitting our API with the SDK from there

#

Which is potentially why the parameter isn't getting passed through

white tulip
waxen cargo
#

Right but what does your API do at that point?

white tulip
#

no idea gotta ask the team xD

waxen cargo
#

haha okay

#

I think that is the source of the issue here

#

From what I can see you are still using our SDK

white tulip
#

hmmm, i see it could be that we are spreading some data in there

#

and its being overwritten by the spread

waxen cargo
#

Yeah I would assume something like that is going on.