#Charge organisations not users

1 messages · Page 1 of 1 (latest)

tacit skiff
#

I have users which will always be part of an organisation and I want to create wallets for these organisations. Currently, the email and the name field are mandatory, plus, I can't give my own id to these "customers". Is there any guide available for these?

verbal lynxBOT
#

To create wallets for organizations and manage them as customers in Dodo Payments, you need to follow these guidelines:

  1. Creating Customers (Organizations):

    • You must provide mandatory fields such as email and name when creating a customer. This is required to identify and manage customer records within Dodo Payments.
    • Here's a basic example in JavaScript to create a customer:
      import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: 'Your Bearer Token',
});

const customer = await client.customers.create({
  email: '[email protected]',
  name: 'Organization Name',
});

console.log(customer.business_id);
    • Similar methods are available in other programming languages like Python, Go, Java, and Ruby【4:1†source】.

  2. Assigning Custom IDs:

    • Dodo Payments currently does not support assigning custom IDs to customers directly through the API. Customers are identified using the system-generated customer_id. You will need to map your own IDs to these system-generated IDs in your application logic.

  3. Creating Wallets for Customers:

    • Once a customer is created, you can manage wallets associated with them. Here’s how you can list wallets for a customer:
      const wallets = await client.customers.wallets.list('customer_id');
console.log(wallets.items);
    • This method requires the customer_id to fetch the wallets【4:2†source】.

  4. Using the API:

    • Ensure you have a valid API key and bearer token to authenticate your requests.
    • Always check for API responses and handle errors such as invalid parameters or request failures gracefully.

For more detailed guidance and examples in other languages, please refer to the official Dodo Payments documentation.

Helpful Links:

umbral musk
#

Hey @tacit skiff
Can you please share your use case in detail?
how are you tracking "users" of an organization. Is it through custom onboarding? Is there any limit to how many users of an organization can access the product?

tacit skiff
#

That’s managed by clerk

#

My application has two first class entities, one being individual users and the next being the organisations they’re part of.

Because dodopayments requires that I send an email and name over when creating a customer, it causes a problem because orgs don’t have an email themselves. The bills are to be generated for orgs not individual users.

I have currently found a workaround by creating a checkout sessions rather than a customer.

Although when I move to using your ledger that’s when I see the same problem occurring

tacit skiff
#

@plucky marten any updates on how to do this?

tacit skiff
#

For anyone who finds this later, using synthetic emails is what I'm personally proceeding with. Something like billing+{org_id}@domain.tld

The only bottleneck here is management of emails being sent for invoice and payments that must be handled on your own. Which seems to be the cheapest tradeoff.

If you're being brave you could setup email forwarding with an email server.

As for Dodo, I believe you should solve these problems before you jump onto adding snow & games to my payments dashboard 🙂

plucky marten
#

@bright musk can you chat with @tacit skiff and share me the exact requirements here?

#

I feel this can be achievable with the current system that we have.

bright musk
#

@tacit skiff - Please check dms

bright musk
#

@tacit skiff @plucky marten
I had a conversation with Advat regarding this use case.

Use case:
He is working on a ticketing tool where organizations are created and users belong to those organizations. Currently, he creates subscriptions for users using a dummy email tied to the organization’s domain each time a subscription is created. However, he would like the option to either make the customer email optional

Alternatively, he’s looking for support for an external_id flag, where he can pass the organization ID as the external ID and use that to track subscriptions and org.

#

@tacit skiff
Making the customer email optional is not possible, as the email is the primary identifier for both the customer and the merchant, and it’s the only communication source for them and for us.

Regarding the external ID requirement, we do support this—you can use the metadata field in checkout to pass and track an external IDs.
Please refer - https://docs.dodopayments.com/api-reference/metadata
https://docs.dodopayments.com/api-reference/checkout-sessions/create#body-metadata-one-of-1

tacit skiff
#

The external id without the optionality of email is not particularly useful to me.

I’m aware of the checkout metadata and I am currently using it.

To finalise the issue and clear the record I’d like to properly note it down.

————————

I’m working on an AI SaaS tool targeting B2B users. I only deal with organisations, so the customer paradigm that dodo has is a hindrance because organisations don’t have a single email — they are a group of users.

If I put the org creators email as the customer email I run into two problems:

  1. If that person has multiple organisations, we are now tying multiple subscriptions to a single email which I don’t want to do because in the customer portal I want to just show the logged in organisation’s subscriptions.

  2. (The bigger problem) If the owner of a team is to leave the subscriptions will have to be moved to another admin which from what I can tell isn’t supported. On top of that owner emails and billing emails are separate entities in our books.

All this only becomes a problem because I’m not just using your subscriptions product but also using the seat based billing example that you provide where subscriptions are updated based on users joining and leaving an organisation (like slack)