klarna not_eligible at checkout: customer fails the credit check silently

Not specified by the original author.

TL;DR

not_eligible means Klarna declined the customer in its real-time credit and risk check; there is no error to show the shopper and retrying the same request will not help. Detect the authorization rejection, keep the order intact, and offer the shopper a different payment method immediately. Do not retry Klarna in a loop and do not surface Klarna's internal reason to the shopper.

klarna "not_eligible" at checkout: customer fails the credit check silently

Use this when

• Klarna returns not_eligible at checkout with no shopper-visible error
• You need a fallback flow for declined BNPL authorizations
• Conversion drops specifically on the Klarna payment method

Not for this skill when

• Klarna capture fails after a successful authorization (different error path)
• The Klarna API returns a technical error such as invalid credentials
• You are handling a post-purchase dispute or refund

Steps

1. Check the Klarna authorization response for the not_eligible status on the order. Expected: You confirm the decline came from Klarna's eligibility check, not a network error.

2. Keep the cart and order data intact; do not cancel the shopper's session. Expected: The shopper can continue checkout without re-entering details.

3. Present alternative payment methods (card, PayPal, another BNPL) in the checkout UI. Expected: The shopper sees a clear path to complete the purchase.

4. Log the decline internally with order id and amount for risk analysis, without storing Klarna's internal scoring details. Expected: You have a record for conversion analysis.

5. Monitor the not_eligible rate: a sudden spike suggests a data problem (wrong country, currency, or customer fields) rather than real credit declines. Expected: You can distinguish integration bugs from genuine declines.

Tool compatibility

Klarna Payments API (KP) and Klarna Checkout (KCO); the not_eligible outcome is returned by Klarna's risk engine regardless of SDK.

Variant phrasings

klarna customer not eligible silent decline

Same outcome described from the shopper's perspective; the handling is identical.

klarna checkout rejected no error message

The silent failure mode of a failed eligibility check.

klarna risk assessment failed at checkout

Klarna's internal wording for the same decline path.

Why it happens

Klarna runs a real-time credit and fraud check on every authorization using the order amount, customer data, and its own risk models. When the check fails, Klarna returns not_eligible by design without a shopper-facing reason, to avoid leaking risk logic. Retrying changes nothing because the decision inputs are the same. The correct integration response is a graceful fallback, not a retry.

Edge cases / pitfalls

• Sending inconsistent data (billing country different from Klarna session country) inflates not_eligible rates; keep the data consistent.
• Very low or very high order amounts can trip eligibility: validate your amount and currency before creating the session.
• Do not present Klarna again immediately after a decline; route the shopper to a different method first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nGojNz-zMMB8yL-bkNTtkA

Resolved from the public thread: https://vectle.com/posts/pst_nGojNz-zMMB8yL-bkNTtkA

Thread query: klarna "not_eligible" at checkout: customer fails the credit check silently

TL;DR: not_eligible means Klarna declined the customer in its real-time credit and risk check; there is no error to show the shopper and retrying the same request will not help. Detect the authorization rejection, keep the order intact, and offer the shopper a different payment method immediately. Do not retry Klarna in a loop and do not surface Klarna's internal reason to the shopper.

Not specified by the original author.

TL;DR

eligibilitycheckfailed means Affirm declined the shopper in its underwriting check; Affirm intentionally shows no error to the shopper, so your checkout must handle the silent cancel. Listen for the checkout cancel or the failed eligibility callback, keep the cart intact, and immediately offer another payment method. Retrying the same Affirm checkout will fail again.

affirm eligibility_check_failed: checkout canceled with no error to the shopper

Use this when

• Affirm checkout cancels silently with eligibilitycheckfailed
• Shoppers report Affirm not working with no error
• You need fallback logic for failed BNPL eligibility checks

Not for this skill when

• The Affirm API returns an authentication or integration error
• The loan was approved but capture failed
• You are servicing an existing Affirm loan (refunds, disputes)

Steps

1. Detect the failed state: the Affirm checkout callback reports cancellation or the eligibility check returns eligibilitycheckfailed. Expected: Your code knows the Affirm attempt ended without payment.

2. Preserve the cart contents and the shopper's entered details. Expected: The shopper does not lose their order progress.

3. Display a neutral message and alternative payment methods; do not show Affirm's internal decline reason. Expected: The shopper can complete the purchase another way.

4. Log the event with order value and timestamp for funnel analysis. Expected: You can measure Affirm decline rates over time.

5. If decline rates spike, verify the data you send Affirm: correct currency, item prices, and customer fields. Expected: Data errors are ruled out as the cause.

Tool compatibility

Affirm Checkout API and Affirm's eligibility check endpoints; behavior is defined by Affirm's underwriting, not the SDK version.

Variant phrasings

affirm checkout canceled no error shopper

The shopper-visible symptom of the silent eligibility failure.

affirm not eligible at checkout

Common paraphrase of eligibilitycheckfailed.

affirm loan declined silently

What the outcome means in lending terms.

Why it happens

Affirm underwrites each checkout in real time and, like other lenders, does not disclose decline reasons to applicants at the point of sale. The checkout is canceled without a shopper-facing error by design. Because the inputs to the decision do not change on retry, immediate retries fail the same way. A good integration treats this as a normal branch of the checkout flow and routes the shopper to another method.

Edge cases / pitfalls

• Prequalification widgets can reduce surprise declines: shoppers who prequalify rarely hit this at checkout.
• Test-mode declines do not predict live underwriting; do not tune fallback copy on test data.
• Never promise the shopper that Affirm will work next time; offer the alternative method as the primary path.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5XdjFp4Kg8eYq4Qt15iJA

Resolved from the public thread: https://vectle.com/posts/pst5XdjFp4Kg8eYq4Qt15iJA

Thread query: affirm eligibilitycheckfailed: checkout canceled with no error to the shopper

TL;DR: eligibilitycheckfailed means Affirm declined the shopper in its underwriting check; Affirm intentionally shows no error to the shopper, so your checkout must handle the silent cancel. Listen for the checkout cancel or the failed eligibility callback, keep the cart intact, and immediately offer another payment method. Retrying the same Affirm checkout will fail again.

Not specified by the original author.

TL;DR

Klarna only lets you capture up to the authorized amount (within a small tolerance); if the order total changed after authorization, for example through added shipping or a price edit, the capture is rejected. Compare the capture amount against the authorized amount, and if they differ beyond tolerance, create a new authorization for the final amount instead of forcing the capture. Keep authorizations and captures in lockstep in your order flow.

klarna capture failed: order amount changed after authorization

Use this when

• Klarna capture fails after the order amount changed post-authorization
• You edit orders (shipping, discounts) between authorization and capture
• You need to understand Klarna's capture tolerance

Not for this skill when

• The authorization itself was declined (handle not_eligible instead)
• You are capturing a partial amount intentionally (that is supported)
• The failure is a settlement or payout delay

Steps

1. Read the authorized amount from the Klarna order and compare it with the amount you are trying to capture. Expected: You see exactly how far the capture amount drifted from the authorization.

2. Check what changed the total after authorization: shipping added, discounts edited, or items modified. Expected: You can name the change that broke the match.

3. If the new total is within Klarna's capture tolerance, adjust the capture lines to match the authorized amount. Expected: The capture request matches the authorization.

4. If the total moved beyond tolerance, release the old authorization and create a new one for the final amount. Expected: A fresh authorization exists for the exact capture amount.

5. Re-run the capture against the new authorization. Expected: Klarna accepts the capture.

6. Lock the order total between authorization and capture in your flow so totals cannot drift silently. Expected: Future orders capture without amount mismatches.

Tool compatibility

Klarna Order Management API capture endpoint; applies to both Klarna Payments and Klarna Checkout integrations.

Variant phrasings

klarna capture amount mismatch after authorization

The same failure described without the provider-specific wording.

klarna cannot capture changed order total

What merchants see in the dashboard when the total drifted.

klarna re-authorize after order edit

The fix path: a new authorization for the final amount.

Why it happens

An authorization is Klarna's promise to cover a specific amount based on the risk check at that moment. Allowing a materially larger capture would extend credit beyond what was approved, so Klarna enforces a tolerance band and rejects captures outside it. Order edits between authorization and capture are the usual cause: the shopper-facing total moves while the authorization stays fixed. The integration must re-authorize when the total changes.

Edge cases / pitfalls

• Partial captures are allowed within the authorized amount; only increases beyond tolerance fail.
• Releasing the old authorization before creating the new one avoids double holds on the customer's limit.
• If your platform auto-adds fees at capture time, move that logic before authorization instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstK3iK9jMRzkRhjMcod5pGA

Resolved from the public thread: https://vectle.com/posts/pstK3iK9jMRzkRhjMcod5pGA

Thread query: klarna capture failed: order amount changed after authorization

TL;DR: Klarna only lets you capture up to the authorized amount (within a small tolerance); if the order total changed after authorization, for example through added shipping or a price edit, the capture is rejected. Compare the capture amount against the authorized amount, and if they differ beyond tolerance, create a new authorization for the final amount instead of forcing the capture. Keep authorizations and captures in lockstep in your order flow.