#nulsen_api

1 messages · Page 1 of 1 (latest)

frigid badgerBOT
#

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

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

terse kilnBOT
tropic zinc
#

We have a large platform with thousands of users and we have a field where our customers can change their invoice email address. The users can select between card and invoices on our platform, and we want to make sure that the invoices are sent to the email they want.

However, when the account is created when they sign up, their own email are added as the email address and also billing address and the checkbox "Same as account email" are not checked. So when they change their invoice email address recipient in our system, the customer object just gets the primary email changed, but not the billing email, since we can't touch it, so the emails are sent to the wrong email address.

Also, we've tried tracking this via webhooks to warn us when emails are sent to wrong email, but no webhook events are sent when emails are delivered. And when the invoice.sent webhook event triggers, only the customer primary email is available, not the desired billing email.

I need your help to find a way for our customers to change their billing address, we're getting a lot of support regarding this and it's eating our time.

I've figured there are multiple ways to fix this, but i don't know if i can do any of them.

  • Including billing email in the API
  • Include the setting "Same as account email" in the API
  • Create a global setting in the UI so "Same as account email" is ALWAYS checked by default when an account is created.
  • Include the actual billing email in the invoice.sent webhook event.
  • Create a new webhook event for emails that are delivered from your platform.
#

Test customer: cus_LSoje00oCTAsoH

compact osprey
#

hi! yeah some of those fields are Dashboard only

tropic zinc
compact osprey
#

yeah when you have separate addresses like that, those are not available in the API, it's a Dashboard only feature right now

tropic zinc
#

Then when the account is created, the "Same as account email" must be ticked, since I cannot change it after the first time

#

Maybe it's best if i create the account without email if possible and then right after i'll update the customer with their email, then it might get excluded from the billing email field?

compact osprey
#

well you can just set email in the API when creating the Customer object and not use the Dashboard at all

tropic zinc
#

The issue is that when i do that, the email field of both account email and billing emails are set. When our customers attempt to change that in our platform, only the account email are changed. So i must be able to leave the billing email empty

compact osprey
#

When our customers attempt to change that in our platform
how do they do that exactly?

#

i.e what API is your platform calling or so on

tropic zinc
#

Just a field, and i send a customer update with the new email via Node SDK

#

My goal is to either: Ignore/leave the billing email empty OR somehow include the email that an invoice was actually sent to in the webhook event invoice.sent or invoice.created so i can at least handle it manually

#

If just readonly

compact osprey
# tropic zinc Just a field, and i send a customer update with the new email via Node SDK

that makes perfect sense, but then I don't see how you'd run into a problem. It's only if you also update the Customers in the Dashboard and use the 'add more receipients' functionality that this other separate billing email(internally, email_cc) is set; if you're only ever using the API then only email is set and mutated and it's the only address emails get sent to

tropic zinc
#

When i create the customer with an email, the email is mutated to the billing email address.
Then when i update the customer email again via the node SDK, the email is NOT mutated, only the account email is updated.

#

The billing email remains the old email and the invoices keeps going there

compact osprey
#

I don't really follow and that's not what I see.

let customer = await stripe.customers.create({
    email: "test@example.com",
});
await stripe.customers.update(customer.id,{
    email:"test2@example.com",
})
image.png image.png
tropic zinc
#

I'll give you examples from me, but meanwhile, thanks for being awesome

compact osprey
#

in your example customer you posted, you did use the Dashboard

#

it's just a feature request that's been open for years (search on this Discord for "email_cc" or "email_to") and it is a pain. There's some work to replace this with a newer system using some new, public fields. I believe there is a beta for that and in theory you can escalate via support to get access to that, might help you. But otherwise unfortuantely this is just a known pain point that these fields can be set by the Dashboard and can't be seen in the API.

tropic zinc
#

I see, at least it's coming, i've contacted you like a year or 2 ago regarding this, but this is the first time i was able to speak to someone who actually knew something

#

Ok somehow now the new customer i created got this ticked by default

image.png
#

Did you have any issues with this a few months ago? We migrated like 500 customers from another platform and then i created stripe customers of every single customer. And all of those 500 was created with this unticked

#

Or maybe like 300-400 at least

compact osprey
#

I'm not aware of anything but maybe there was something or maybe it's a quirk of the migration tooling

tropic zinc
# 
stripeCustomer = await stripe.live.customers.create({
    name: newOrganization.businessName,
    email: newOrganization.address.invoice.email ?? currentUser.email,
    description: newOrganization.businessName,
    address: {
        country: 'SE',
        line1: '',
    },
    preferred_locales: [
        'sv-SE',
    ],
    metadata: {
        organizationId: newOrganization._id.toHexString(),
        promoCode: promoCode ?? null,
        source: source ?? null,
        currentSystem: currentSystem ?? null,
    },
})
#

This is how i created them all

#

So yeah, pretty weird. But hey, it's working now at least

tropic zinc
compact osprey
#

oh apparently there was a bug, I just found a PR from Feburary that fixed an issue with that checkbox

tropic zinc
#

Oh

#

Freaking awesome

#

I know all my issues are solved then

#

THANKS

#

And hmm, how hard is it for you the clean my customer database by ticking that for every customer object for me?

#

Will take an hour or 2 to do that manually

compact osprey
#

well given you'd have to write in and it would have to be escalated and then triaged to the eng team to see if they have tooling to set that particular field in bulk(which I'm not aware of) and then they have to prioritise the work, plus that we have a general policy of not setting things that you're able to set yourself, I think doing it manually might be better. But I agree it's really painful to do all that clicking, I'm really sorry

#

I'm just being pragmatic but it's also 100% reasonable to ask us to try and fix it, we do that sometimes

tropic zinc
#

Haha i get it. Maybe not a UPDATE customers SET checkbox = true WHERE customer = "foo" is not something you do in that kind of prod DB

#

I'll start the cleaning process then. Thanks for the support again. Hope you have a great day

frigid badgerBOT
lost elk
#

👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!

tropic zinc
#

No i'm satisfied, not even mad that i have to cleanup all my customer, I'm just glad the issue is resolved.