Why provider_customer_id is empty right after creating a customer with sync_with_provider

When you create a customer with payment_provider: stripe and sync_with_provider: true, then immediately call findCustomer, provider_customer_id sometimes comes back empty or undefined. This is expected. Lago creates its own customer record and returns right away, but the payment provider customer is created afterwards on a background queue, so the id is not yet populated when a follow-up call arrives moments later. The delay depends on how busy the queue is and can occasionally exceed a minute.

How sync_with_provider and sync work together

These are two separate billing_configuration fields that do different things.

sync_with_provider tells Lago to create the customer in the payment provider at all. With this flag alone, the createCustomer response returns before the provider customer exists, and the provider customer is created asynchronously.

sync controls whether that provider creation happens inline during the createCustomer call instead of being queued. Per the API reference, set sync to true to create the customer in the payment provider synchronously with the Lago customer creation process. It applies only when provider_customer_id is null and the customer is being created in the provider through Lago. The default is false.

So sending sync_with_provider: true without sync: true routes provider creation through the background queue, which is the source of the delay. Sending both attempts the creation during the request, so a follow-up findCustomer has provider_customer_id available.

One caveat on sync: true: it is not a guarantee. If the provider is unreachable or returning errors at that moment, Lago falls back to background retries, and the same delay reappears on that path.

What to use

There are three ways to handle this, and they can be combined.

1. Set billing_configuration.sync: true. Smallest change. Removes the delay on the normal path and falls back to async retries if the provider hiccups.

2. Listen for the customer.payment_provider_created webhook. Lago fires this once the provider customer has been created, so it is a reliable readiness signal that also covers the fallback case. Best if you would rather not depend on timing at all.

3. Create the provider customer yourself and pass billing_configuration.provider_customer_id. The id is present the moment the Lago customer exists, with no waiting and no race. A good fit if you already call the provider directly for other things.

Combining options 1 and 2 covers both the fast path and the delayed fallback.

This article reflects guidance drawn from customer case resolutions. It is not officially supported documentation and may not apply to all situations.