Use this article to structure your checkout so Ingrid Promise shows accurate delivery options, your delivery data stays correct, and your checkout converts well. You will learn the correct order of checkout steps, how that order works when a payment service provider (PSP) collects the address, and which checkout structures to avoid.
This article is for retailer technical staff: chief technology officers (CTOs), tech architects, project leads, and developers who build or maintain the checkout. You do not need deep application programming interface (API) knowledge to read it. Technical terms are explained where they appear, and specific API calls or code are clearly marked so non-developers can skip them without losing the bigger picture.
Why checkout structure matters for Ingrid Promise
The order in which a checkout presents information to the consumer directly affects conversion rate, address accuracy, and delivery precision.
Many retailers still use checkout flows that were designed years ago, where delivery options are shown before the full address is collected. This legacy checkout structure creates real problems:
Wrong delivery options. The system approximates based on the center of the zip code area, but no one lives at the center of a zip code. Consumers often see pickup points that are far from their actual home, such as locations on the opposite side of the city.
Broken selections. A consumer picks a delivery option, then enters a full address later in the payment step. If the address changes the zip code area, the selected option may become invalid, but the checkout often does not update it.
Duplicate data entry. The consumer is asked for address information more than once, which slows down the checkout and increases drop-off.
Support burden. Incorrect deliveries, wrong pickup points, and failed shipments all generate support tickets and returns.
These are not theoretical risks. They are documented issues seen across retailers using legacy checkout structures.
Bottom line: The structure of the checkout, not just its visual design, determines whether it converts well and whether delivery data is accurate.
The correct checkout structure with Ingrid Promise
A well-structured checkout follows four steps, always in this order. Each step feeds the next one with the data it needs. Skipping a step or changing the order breaks the chain.
Summary of the checkout flow
The table below shows the four checkout steps, what each step contains, the data it produces, and which later step uses that data.
Step | What | Data produced | Used by |
Cart | Products, quantities, totals | Cart contents, total value | Delivery calculation |
Address | Full name, street, city, zip, email, phone | Verified delivery address | Delivery options, payment prefill |
Delivery | Carrier options, pickup points, prices | Selected delivery method and cost | Order total, payment |
Payment | Payment method, confirmation | Completed order | Fulfillment, booking |
Each step feeds the next. The checkout structure is sequential and intentional.
Checkout step 1: Cart
What the cart step does: The cart displays everything the consumer intends to buy: products, quantities, prices, and the total.
Why the cart comes first: The cart is the foundation of the checkout. Delivery options depend on what is in the cart: total weight, dimensions, product categories, warehouse availability, and total value (which may determine free shipping thresholds). The cart must be established before anything else can be calculated.
What the consumer sees in the cart step:
Product list with images, names, quantities, and line prices
Cart total
Option to edit quantities or remove items
A clear call to action to proceed to checkout
What happens technically in the cart step: When the consumer moves from cart to checkout, your backend sends the cart data (items, value, currency, country, and language) to the Ingrid API to create a checkout session. This session is the container for all Ingrid Promise delivery logic that follows.
Checkout step 2: Customer information and address
What the address step does: The address step collects the customer information required to create the order: full delivery address (street, city, postal code), name, email, and phone number.
Why the address comes second, and why this is critical: Delivery options are address-dependent. A zip code alone is not enough for accurate results. The full street address determines:
Which carriers can deliver to that specific location
The nearest pickup points, sorted by actual distance
Accurate delivery time estimates
Whether special services (for example, evening delivery or parcel locker) are available. Some of these services depend on the street address, street number, or even house number.
Collecting the full address before showing delivery options eliminates the most common checkout problems: wrong options, broken selections, and redundant data entry.
What the consumer sees in the address step:
A localized address form adapted to the destination country (different countries have different address formats). Using localized address formats is critical for accurate address collection. If the address structure does not match what the destination country's carrier APIs expect, label production in the warehouse will fail, preventing shipment.
Fields for first name, last name, street address, apartment or floor, postal code, and city
Email and phone number fields (required for carrier communication and delivery notifications)
Optional: company name, care-of, billing address
Autocomplete suggestions as the consumer types, reducing errors and speeding up input
Address validation that catches mistakes before they cause delivery failures
The Address form, part of Ingrid Identify, handles all of this as a built-in component. The Address form provides:
Country-specific field layouts
Address autocomplete and validation powered by the Ingrid Locate service
An address book where returning consumers can select a saved address with one click
Verified, standardized addresses that reduce carrier lookup failures
Key point: By collecting the address in step 2, every step that follows has the data it needs. The consumer never has to enter their address again.
Checkout step 3: Delivery options with Ingrid Promise
What the delivery step does: The delivery step presents the available delivery options (home delivery, pickup points, parcel lockers, in-store collection) based on the consumer's full address and cart.
Why delivery comes third: Now that the system knows what the consumer is buying and where it needs to go, Ingrid Promise can calculate precise delivery options. This is where the core intelligence of Ingrid Promise is applied:
Real-time carrier queries return actual delivery dates and prices
Pickup points are sorted by proximity to the consumer's street address, not approximated from the zip code center
Options that are not available for that specific address are excluded
Delivery rules configured by the retailer shape what the consumer sees
What the consumer sees in the delivery step:
A clear list of delivery options grouped by type (for example, home delivery, pickup, express)
For each option: carrier name or label, estimated delivery date, and price
For pickup options: a map view showing locations, distances, and opening hours
A preselected recommended option (configurable by the retailer)
What happens technically in the delivery step: The Checkout widget, part of Ingrid Promise, renders the delivery options inside the checkout page. When the consumer selects an option, the Checkout widget fires events that your system listens to, updating the order total with the correct shipping cost.
Checkout step 4: Payment
What the payment step does: The payment step collects payment details and confirms the order.
Why payment comes last: At this point, the checkout already has:
The full cart with correct totals
The verified delivery address
The selected delivery option with its price
The payment step only needs to handle payment. There is no need for the payment service provider (PSP), whether Klarna, Adyen, Kustom, Walley, Avarda, or another, to collect the customer's address again. The address data from step 2 can be passed directly to the PSP to pre-populate any required fields.
This means:
No duplicate address entry: the consumer never types their address twice
No conflicting data: there is a single source of truth for the delivery address
Faster checkout: fewer fields to fill means faster completion
Cleaner payment experience: the PSP section is lean, focused only on payment method selection and confirmation
What the consumer sees in the payment step:
Payment method selection (card, invoice, wallet, and so on)
Pre-filled billing information (defaults to the delivery address unless changed)
Order summary showing cart and delivery cost
Confirm and pay button
What changes when a PSP owns the address form
The four-step checkout structure described above is the recommended approach for Ingrid Promise. However, some retailers use a payment service provider (PSP), such as Klarna Checkout (KCO), Kustom, Qliro, Walley, or Avarda, that provides its own address form as part of the payment experience.
In these setups, the PSP collects the customer's address, not Ingrid. This does not change the ideal structure of the checkout. The order should still be: cart, address, delivery, payment. What changes is how the integration works and who is responsible for passing data between systems.
How a PSP-owned address form changes the Ingrid Promise integration
When a PSP owns the address form, the PSP and Ingrid Promise run as separate components (typically iframes) that cannot communicate directly. Your backend must act as the bridge between them.
The table below shows the key differences between using the Ingrid Address form (standard) and a PSP-owned address form.
Aspect | Ingrid Address form (standard) | PSP-owned address form |
Who collects the address | Checkout widget, part of Ingrid Promise | PSP (Klarna, Kustom, Qliro, and others) |
How Ingrid gets the address | Automatically, within the widget | Your backend must pass it via API |
Address validation | Built-in (autocomplete and Locate) | Depends on PSP capabilities |
Integration complexity | Mid: fewer moving parts | Low: requires only one dependency instead of two dependent components that need to be synced |
Risk of data mismatch | Low: single source of truth | Low: single source of truth |
Address form configuration | Configured in Ingrid | Configured in PSP, Ingrid Address form disabled |
Scale and coverage | Global reach, locally adapted | Typically not locally adapted at global level |
How the address data sync works from the PSP to Ingrid Promise
When the PSP collects the address, you must ensure Ingrid Promise receives it so delivery options can be calculated. The typical flow:
The consumer enters an address in the PSP form (or the PSP auto-fills it from a cookie or logged-in profile).
The PSP notifies you that the address has changed (via a callback or frontend event).
Suspend the Checkout widget to prevent conflicts (not needed in Headless integrations).
For iframe integrations: send the address to Ingrid via a
session.updateAPI call with thesearch_addressfield.Resume the Checkout widget, which now recalculates and displays delivery options based on the new address.
Ingrid Promise returns updated delivery options, and the consumer sees accurate delivery options tailored to their specific address.
The reverse also applies: if the consumer changes their address inside the PSP after selecting a delivery option, the same sync must happen again.
Challenges specific to a PSP-owned address form
A PSP-owned address form brings five specific challenges for an Ingrid Promise integration:
Timing and ordering. Some PSPs present address and payment together. If the consumer sees delivery options before completing the address, the same problems from the legacy structure return: wrong options and broken selections. The ideal solution, even with a PSP-owned address form, is for the PSP to collect the full address first, then pass it to Ingrid, and show delivery options within the PSP's own context before presenting payment.
Limited address updates. Some PSPs (notably Klarna KCO) restrict how many times the address can be updated after a session is created. This means the sync logic must be efficient. Avoid unnecessary updates.
Address validation gaps. PSPs may not validate addresses as thoroughly as the Ingrid Locate service. This can result in incorrect addresses reaching the carrier, leading to failed deliveries.
Fallback complexity. When Ingrid owns the address form and Ingrid becomes unavailable, you need a fallback for both the address form and delivery options. When the PSP owns the address form, the fallback only needs to cover delivery options, but you must still handle the scenario where Ingrid cannot return options for a given address.
Disabling the Ingrid Address form. When the PSP owns the address, the Checkout widget must be configured to not show its own address form (including the postal code field). Do this by setting
disable_address_form: truein the widget configuration. If this is not set correctly, the consumer will see two address inputs, one from Ingrid and one from the PSP, which is confusing and breaks the flow.
A PSP integration with Ingrid Promise done right
The best PSP integrations with Ingrid Promise maintain the four-step structure within the PSP context:
Cart is displayed above or before the PSP component.
The PSP collects the full address as the first thing inside its component.
Ingrid Promise delivery options are rendered inside the PSP context, using the address the PSP collected.
Payment follows as the final step within the PSP.
This is the pattern used in modern Klarna and Kustom integrations where Ingrid is embedded as a delivery method inside the PSP. The structure is preserved. Only the technical wiring is different.
The principle remains the same: Cart first. Full address second. Delivery options third. Payment last. Whether Ingrid or a PSP collects the address, the order of information must not change.
Common checkout anti-patterns to avoid with Ingrid Promise
The table below shows common checkout anti-patterns, what goes wrong with each, and how to fix it.
Anti-pattern | What goes wrong | How to fix it |
Showing delivery options based on zip code only | Pickup points are inaccurate, and options may become invalid when the full address is entered later | Collect the full address before showing delivery options |
Collecting the address after delivery selection | The consumer selects a delivery option that may not be valid for their actual address | Move address collection before the delivery step |
Asking for the address twice (Ingrid and PSP) | Consumer frustration, slower checkout, potential data mismatch | Choose one address source and disable the other |
Not syncing address changes between the PSP and Ingrid | Delivery options stay stale after an address change, and the wrong carrier is booked | Implement event-driven sync with suspend and resume |
Trusting frontend event data for order totals | Security risk: browser data can be manipulated | Always verify pricing server-side via |
Non-acceptable checkout structures with Ingrid Promise
Some checkout structures break the principle of full address before delivery options. These structures are not acceptable because they reliably create wrong options, broken selections, and duplicate data entry.
Non-acceptable structure 1: Ingrid Promise collects the postal code only, and the PSP collects the full address later
What this structure looks like:
Cart
Ingrid Promise asks for the postal code only (or shows a postal code field)
Ingrid Promise renders delivery options based on the postal code
Later in the PSP (for example, Klarna, Kustom, Walley, or Avarda), the consumer enters the full street address
Why this structure is not acceptable:
A postal code is not precise enough. Pickup points and carrier availability become approximations.
The consumer can select an option that becomes invalid once the full address is known later in the checkout process. If the full address is changed at the bottom of the page, the delivery options might no longer be valid. The consumer must either be informed and scroll back up, or the purchase is completed with the new address and Ingrid Promise must change the delivery options during completion to ensure a valid delivery option.
The checkout ends up with two address sources and conflicting state handling.
How to fix this structure:
Use one address owner.
If the PSP owns the address form, Ingrid must have
disable_address_form: true, and you must pass the PSP-collected full address to Ingrid before delivery options are shown.
Non-acceptable structure 2: Ingrid Promise shows delivery options with no address at all, and the PSP collects the address later
What this structure looks like:
Cart
Ingrid Promise is loaded with no address (no prefill, no prior address step)
Ingrid Promise still displays delivery options (based on defaults, country-level assumptions, or incomplete context)
The PSP later collects the full address
Why this structure is not acceptable:
Delivery options are necessarily inaccurate until the full address exists.
The consumer can make a selection that must be recalculated and potentially overridden later, which creates friction and drop-off.
It reintroduces the legacy problem: delivery before address.
How to fix this structure:
Ensure the flow collects the full address first (with the Ingrid Address form or the PSP address form), then load Ingrid Promise with that address and render delivery options.
If the address changes, use event-driven sync (suspend, then
session.update(search_address), then resume) so options are always recalculated from the latest full address.
Decision guide: who should own the address form with Ingrid Promise?
The table below shows the recommended address form owner for each checkout scenario.
Scenario | Recommended approach |
Building a new checkout or re-platforming | Ingrid Address form. Moderate integration effort, best address quality, full control over the checkout structure. |
Already using a PSP that embeds Ingrid natively (for example, a modern Kustom or Klarna integration) | PSP-owned address with Ingrid inside. The PSP handles the address, and Ingrid Promise renders delivery options within the PSP context. Maintain the correct step order. |
Summary of the correct checkout structure with Ingrid Promise
A checkout that converts well and delivers accurate results follows a simple, non-negotiable structure:
Cart: show what the consumer is buying
Address: collect the full delivery address and customer information
Delivery: display precise delivery options based on that address
Payment: handle payment without asking for the address again
This structure works whether Ingrid or a PSP collects the address. What changes is the integration wiring, not the principle.
When a PSP owns the address form, you take on additional responsibility for syncing data between the PSP and Ingrid. This adds complexity but does not change the goal: full address before delivery options, always.
Every deviation from this structure (showing delivery before address, collecting only zip codes, asking for the address twice) creates friction that reduces conversion and generates downstream problems.
Get the checkout structure right first. The rest follows.