Chargebee customers (billing accounts) can be created and updated from iPaaS.com customers through Outbound Data Flows triggers or Manual Sync, using the Add/Update Chargebee Customer FROM iPaaS.com mapping collection. Each transfer creates the Chargebee customer the first time and updates the same Chargebee customer afterwards, carrying the customer's name, email and company. The customer's primary billing address travels with it through the child collection Add/Update Chargebee Customer Billing Address FROM iPaaS.com. Subscriptions, payment sources and charges stay in Chargebee: these collections never create them.

Enter the iPaaS.com Customer ID on the iPaaS.com Manual Sync page: the numeric id of the Customer record in iPaaS.com. The customer must still pass the mapping filter of Add/Update Chargebee Customer FROM iPaaS.com to be sent, and its primary billing address goes with it. A billing address cannot be sent on its own.

After a successful transfer, iPaaS.com saves the Chargebee customer id as the external ID of the iPaaS.com customer, on a dedicated external-ID record. That record routes every later transfer of the customer to an update of the same Chargebee customer. The default mappings do not send a customer id, so Chargebee generates one (for example, AbC123xYz456QrS78); a subscriber who maps an id of their own must keep it to at most 50 letters, digits and the characters _ - . @.

The billing address is linked with its own external ID: the Chargebee customer id followed by |billing (for example, AbC123xYz456QrS78|billing). Chargebee keeps one billing address per customer, so each later transfer updates that same address.

Deleting Chargebee customers FROM iPaaS.com is not supported, because a customer's invoices and subscriptions depend on it. A delete that reaches this collection stops with CHGB-BIZL-1005 and nothing is deleted in Chargebee, so do not subscribe to the customer/deleted trigger for it. A billing address is never deleted on its own either. Remove or archive customers in Chargebee itself.

Add/Update Chargebee Customer FROM iPaaS.com can write Chargebee customer custom fields. The billing address collection cannot.

The integration sends only destination custom fields whose names begin with cf_. A blank value is never sent, so it never clears a Chargebee custom field, and a custom field edited in Chargebee since the last sync is protected like any other field (see Values Kept in Chargebee).

Whether a transfer creates or updates the Chargebee customer depends on whether the iPaaS.com customer is already linked to one, not on which trigger fired.

These collections write Chargebee customers and their billing address. These collections work on the same records in the opposite direction:

Important: When both directions are active, decide which system is the source of truth for each customer field and review both directions' filters before enabling them.

When the customer_created and customer_changed scopes of Add/Update Chargebee Customer TO iPaaS.com are Active, Chargebee reports every customer this collection creates or updates, and iPaaS.com runs a Customer TO iPaaS.com transfer of the same customer. Subscribers or their MiSP watching activity will therefore see at least one TO iPaaS.com transfer after each FROM iPaaS.com write. That transfer brings Chargebee's values, including the billing status fields, back to the same iPaaS.com customer. For a change to the customer's own fields, such as the name or email, one returning transfer follows and then the echo stops: it does not start another FROM iPaaS.com transfer, so the two directions do not keep sending the customer back and forth. A billing address change is written to Chargebee in more than one step and may come back as more than one TO iPaaS.com transfer; subscribers or their MiSP should validate in a staging environment that billing address changes settle before relying on it in production.

Before it creates a Chargebee customer, the integration searches Chargebee for customers with the same email. Email is the only match field and cannot be changed. Collision handling runs only when a customer is created; an update already has its Chargebee link and never searches.

The four Collision Handling Method options:

With this integration, Remap and Link and Update and Link end the same way: the matched customer is linked and carries the iPaaS.com values. A matched customer has never been written by the integration, so there is no earlier sync to compare against: under any method that updates it, the iPaaS.com values replace Chargebee's values for every field these collections carry. Subscribers or their MiSP who want to review each match before it is written should choose Error.

No method set: with a single match, the integration never creates a second customer itself; it hands the match back to iPaaS.com for the Collision Handling Method to resolve. With no method selected, a Chargebee customer with the same email, including one created moments earlier when Chargebee's email search returns it, is linked to the iPaaS.com customer and nothing is written to it. Do not rely on the collection with no method selected: select a Collision Handling Method on Add/Update Chargebee Customer FROM iPaaS.com before enabling it, and validate the chosen method in a staging environment before relying on it in production.

The billing address collection has no collision handling of its own. It goes with its customer and updates the linked Chargebee customer's billing address.

A create is not protected against being repeated. If Chargebee creates the customer but iPaaS.com does not save the link to it (for example, the transfer fails after the create, or the link is removed), the next attempt treats the iPaaS.com customer as new and creates again:

Chargebee allows several customers with the same email, so it does not stop the duplicate itself. After a customer transfer has failed and been retried, or after a customer's Chargebee link has been removed, subscribers or their MiSP should search Chargebee's customer list for the customer's email. If two Chargebee customers now hold it, keep the one iPaaS.com is linked to (its id is the iPaaS.com customer's external ID) and merge or delete the other in Chargebee before billing starts on it. Until one of them is removed or its email changed, a later create of an iPaaS.com customer with that email stops with CHGB-BIZL-1001.

These collections never overwrite a Chargebee value they do not carry. An update sends only the values that differ from Chargebee's, a blank iPaaS.com value never clears a Chargebee value, and the billing address keeps every Chargebee address field the transfer leaves blank or does not map. Chargebee fields with no mapping here (for example the customer's own phone, payment terms or preferred currency, and the billing address email and state name) keep the values set in Chargebee. Because the FROM iPaaS.com direction writes only changed values, these collections carry no Unmapped Field Overwrite Risk on the Chargebee side; the risk on the iPaaS.com side is covered in the Chargebee to iPaaS.com Customer Mapping Documentation.

The integration also remembers every field it writes to a Chargebee customer: name, email, phone, company, custom fields and each billing address field it sends.

The integration-wide setup (API key, Chargebee Site and the subscription settings) is in the Chargebee Installation Instructions and is not repeated here.

When an iPaaS.com customer that passes the mapping filter is sent by an Outbound Data Flows trigger or Manual Sync, the integration processes it in this order. No other record is transferred first.

When the iPaaS.com customer is not yet linked to a Chargebee customer (create):

When the iPaaS.com customer is already linked to a Chargebee customer (update):

When the Customer TO iPaaS.com scopes are Active, Chargebee then reports the write and iPaaS.com runs at least one Customer TO iPaaS.com transfer of the same customer (see Each Write Comes Back TO iPaaS.com).

iPaaS.com data type: Customer

Description: Creates or updates one Chargebee customer per iPaaS.com customer that passes the mapping filter, with its name, email and company.

Mapping Filter

Filter Description: The filter selects which iPaaS.com customers become Chargebee billing customers. It is a way of choosing customers, not customer data the transfer needs, and subscribers or their MiSP can adapt it or replace it entirely. As shipped, it is an example: it sends only customers whose Categories include a category whose CategoryName exactly matches the text in quotes. Customers with no categories, or without that category, are skipped silently: no error is logged.

Placeholder value — replace during implementation: the template ships with the example filter shown above, which compares each category name with REPLACE with the customer category that marks a billing account. Until it is changed, no customer matches and nothing is sent. Change it to match how billing customers are marked in iPaaS.com, for example:

Subscribers or their MiSP should test the changed filter with a few customers in a staging environment before relying on it in production, because a customer the filter skips logs no error.

Field Mapping Table

Every field in this table is protected against overwriting an edit made in Chargebee (see Values Kept in Chargebee). Fields that subscribers or their MiSP add are checked too: AutoCollection must be on or off, Taxability must be taxable or exempt, and a mapped Id must be at most 50 letters, digits and the characters _ - . @; any other value stops the transfer with CHGB-VALD-1001 before anything is written.

iPaaS.com data type: Customer Address

Description: Writes the customer's primary billing address to the Chargebee customer's billing address, as part of each transfer of its parent customer.

Mapping Filter

Filter Description: Only the address whose IsPrimaryBilling flag is true is sent. Every other address on the customer, including shipping addresses, is skipped. A customer with no primary billing address is still sent, without a billing address.

Field Mapping Table

On an update, every billing address field above that is blank keeps the value Chargebee holds.

Lookup Translation Tables

Chargebee Country FROM iPaaS.com converts the country as iPaaS.com holds it into the code Chargebee requires. The template ships with these rows:

Subscribers or their MiSP must add a row for every other country their customers use, with the country exactly as iPaaS.com holds it on the left and its two-letter code on the right (for example, Australia to AU, or Germany to DE). Until a country has a row, a customer with that billing country stops with CHGB-VALD-1001. Add the row, then send the customer again.

Errors from these collections appear in Dashboard / Integration Monitoring / Error Logs. iPaaS.com retries a failed transfer automatically while its error is active; dismissing an active error stops its retry, but an error already showing Retry Pending is reprocessed anyway. Fix the cause so a retry can succeed. The Chargebee Error Messages article lists every code with its fix. The errors subscribers see most on this flow:

These collections have no initialization. Existing customers are sent as they are created or updated in iPaaS.com, or one at a time with Manual Sync. To send a large set of existing customers, use a bulk sync using Postman.

Related Mapping Documentation