#ashtray-wasp_api

1 messages · Page 1 of 1 (latest)

warm glenBOT
#

👋 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/1231927576956637207

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

trim portalBOT
digital forge
#

👋 happy to help

#

the request you shared, specifically unsets the default_payment_method

#

I'm not sure I understand the issue here

dapper current
#

The issue is that when the next invoice comes, it charges using the default payment method (as expected), but this also results in updating the subscription (see the evt_1P8KmvF9R6Nkg8po01KJRT1K event). I want to avoid having the subscription updated this way. Is there an API way of setting up a subscription to work as expected by me?

digital forge
#

what is the expected behavior?

dapper current
#

The behaviour I want to achieve:

  1. Subscription default_payment_method is null.
  2. The billing time comes, a new invoice is issued
  3. Subscription doesn't get updated to have default_payment_method set to whatever is currently the customer's default payment method.

So basically I want to avoid automatic subscription mutations such as the one that produced the evt_1P8KmvF9R6Nkg8po01KJRT1K event

digital forge
#

but why would you ever get to default_payment_method null unless you unset it?

dapper current
#

I unset it deliberately, so that the charges for the subscriptions are made using customer's default payment method.

#

And I want it to stay like that even when invoices are issued and paid. Trying to figure out if it's possible

digital forge
#

is the customer's default payment method the same one as the subscription's default payment method?

dapper current
#

Before invoice is created:

  • Subscription default payment method is null ✅

After the invoice is created:

  • Subscription default payment method is set explicitly to be what the customer's default payement method currently is ❌
trim portalBOT
thin grail
#

Hi! I'm taking over from my colleague. Please, give me a moment to catch up.

thin grail
#

Sorry for delay, it's quite busy today.

#

I didn't know it works like this, but what you can do it manually unset the default_payment_method on the Subscription after the invoice.paid event.

dapper current
#

The problem with handling this with invoice.paid event is that I can't tell if the subscription had default_payment_method set to null before that.

Anyway, it seems that there's really no easy solution to this. Thanks for help!

thin grail
#

What you can do is look for an customer.subscription.updated event, and check the previous_attributes property. If it contains the default_payment_method: null, you update the Subscription to reset it.

dapper current
#

What's interesting is that this change from default_payment_method: null to non-null that is triggered by invoice creation doesn't even produce an event. I thought that this event: evt_1P8KmvF9R6Nkg8po01KJRT1K describes this change, but it's not it. It just magically changed from null to non-null and there are no logs or events that would explain this.

I did test this using the time simulation in the test mode though. Could that have caused any side effects?

thin grail
#

Test mode has its quirks and exceptions, but this one feels like a deliberate action. The fact that there's no update event though is not ideal, of course.

dapper current
#

Okay, I have no more questions. Thanks for help!

thin grail
#

Happy to help.