Integration patterns

Pattern 1: Checkout payment method

In this pattern, EFL Leasing is one of the payment methods offered during checkout.

High-level flow:

1. Customer chooses EFL Leasing at checkout.
2. Backend initialises configuration and EflClient.
3. Backend obtains auth token and starts a process.
4. Backend calculates offers based on the cart.
5. Frontend displays available offers and redirects the customer to the EFL flow when ready.

Key SDK methods:

• getAuthToken()
• startProcess()
• calculateBasicOffer()
• Customer data submission and verification methods when the customer proceeds.

Pattern 2: Background status polling

In this pattern, your backend periodically polls the EFL API to update the status of leasing processes.

Typical steps:

1. Persist process identifiers when starting a process.
2. Schedule background jobs to poll process state.
3. Use low-level API clients or dedicated EflClient methods to fetch status.
4. Update your own order or contract records based on the results.

This pattern decouples user-facing flows from the timing of external updates.

Pattern 3: Lead capture

You can use the SDK to send leads and contact forms to EFL systems even outside of a full leasing process.

Typical steps:

1. Collect basic contact and interest data from a form.
2. Build a ContactData model.
3. Call EflClient::sendContactForm() to register the lead.
4. Store references returned by the API for later tracking.

This pattern is useful when you want to capture interest before a full purchase flow.

Combining patterns

Most real-world integrations combine these patterns:

• Checkout payment method with background polling.
• Lead capture entry points that later transition into full leasing processes.

The SDK is designed to be used from your own application services so you can compose these patterns according to your domain needs.