Checkout financing decisions on the lender’s side

Eligibility is hard-coded in every partner integration, so a new market waits on a partner release. Decisimo keeps checkout eligibility in one decision flow on the lender’s side.

Start free See financing options

Edit merchant and market rules in one table

Market, merchant category and affordability choose the offer. Every row records a plain-language reason, and adding a market means adding rows. The thresholds, markets and offers in this screenshot belong to a demo case. A rule set handles merchant and market knock-outs that need no score.

Financing options decision table maps market, merchant category and affordability conditions to offers and reasons — The Financing options decision table shows conditions and results for checkout offers. From it, the lender can add market rows and keep a reason with each offer.

Checkout data sources called together

Several sources sit in one data source step and are called at the same time. The step waits as long as its slowest source, rather than their sum. If a source fails, its values are absent and the rules decide what that means. Connect a data source.

Eligibility lookups shows several sources gathered in one data source step. The lender can keep them in the same decision flow and define what missing values mean.

Change a rule without a partner release

A rule change becomes a new release on the same endpoint, so the partner ships nothing. The testing studio runs the decision flow with chosen values before it goes live and shows the offer, reason and release behind them. See decision endpoints and releases.

Testing studio single run showing input values and the resulting offer, reason and release — The testing studio shows a Checkout eligibility run with its offer, reason and release. From that run, the lender can inspect the result before the change goes live.

The obligation stays with the lender behind the checkout

Distribution through a partner does not move the lender’s obligations, as governance explains. Assessing the creditworthiness of a person is an Annex III high-risk use under the EU AI Act, with those obligations applying from 2 December 2027. GDPR Article 22 applies to an automated decline today, and each decision’s input and output can be written to the customer’s own Postgres database.

Questions we get asked

Can eligibility differ by merchant and by market?

A decision table can use merchant category and market as conditions for the offer. Adding a market means adding rows, each with a plain-language reason.

What happens when a data provider is slow or down?

A failed source returns absent values and an error flag in the response, then the decision flow continues. The rules define what a missing value means.

How does a rule change reach every partner?

A changed rule becomes a new release on the same endpoint. The partner keeps calling that endpoint, so the change does not require a partner release.

How can the lender check an eligibility change before it goes live?

The testing studio runs the whole decision flow with chosen values and external calls switched off. It shows the offer, the reason and the release that produced them.

Can fraud data sit in the same decision?

Device and fraud data can sit with a credit bureau and merchant profile in one data source step. The sources are called at the same time, and the rules use their returned values. See fraud decisioning for the wider use case.

Start with your checkout eligibility

Create the decision flow, add your merchant and market rules, then run it from the lender’s endpoint.

Start free