Skip to content

Correct two documented claims that measurement contradicts - #19

Open
sveneberth wants to merge 1 commit into
developfrom
docs/klarna-server-side-and-item-rounding
Open

Correct two documented claims that measurement contradicts#19
sveneberth wants to merge 1 commit into
developfrom
docs/klarna-server-side-and-item-rounding

Conversation

@sveneberth

Copy link
Copy Markdown
Member

Two statements in AGENTS.md did not survive being measured. Both are documentation-only
changes.

Klarna does work server-side

AGENTS.md stated flatly that the client-side payment types "cannot be exercised
server-side", and that creating one "yields an empty resource that the provider rejects
further down the flow — Klarna answers COR.800.400.160".

Measured against the sandbox, following the flow to the end:

  1. createPaymentType(Klarna()) — empty body, as the file describes
  2. authorize with customerId, basketId and a public returnUrlpending, plus a
    redirectUrl
  3. the customer confirms on the Klarna page behind that URL (playground login: any German
    test number, any 6-digit OTP except 999999)
  4. the payment then reports:
state    : pending
amount   : {"total": "100.0000", "charged": "0.0000", "remaining": "100.0000"}
  authorize    success    amount=100.0000

No COR.800.400.160. So the empty resource is filled in by the redirect step, and what
fails is skipping that step — not creating the type server-side.

The other affected types (Card, PayPal, Apple Pay, Google Pay, iDEAL, Click to Pay) were
not re-measured. The claim is therefore marked unverified for them rather than turned
around wholesale. The sandbox suite still does not drive Klarna, for the reason the file
now gives: the redirect step needs a browser and would place a real order on every run.

The item-rounding hazard is not theoretical

The note that BasketItem.serialize does not round while Basket.serialize does (#18)
read like a corner case about float residue. It is reachable with ordinary arithmetic: a
three-unit line with amountVat=15.97 * 3 produces 47.910000000000004, and the API
refuses the whole basket with

API.600.200.133  Amount 47.910000000000004 has more than 4 positions after the decimal point.

That error code appeared nowhere in the repository. Until #18 is fixed, a caller has to
round every item amount itself — worth knowing at the point where the rounding rule is
documented.

Verification

  • pytest — 291 passed, 31 deselected
  • pycodestyle --diff — clean
  • No source changes; AGENTS.md and one test module docstring only.

Two claims corrected by measurement.

**Klarna.** "These types cannot be exercised server-side" was too absolute. Measured:
`createPaymentType(Klarna())` with an empty body, an `authorize` with `customerId`,
`basketId` and a `returnUrl`, and the customer confirming on the page the returned
`redirectUrl` leads to, ends with the payment reporting `authorize: success` for the
full amount -- no `COR.800.400.160`. The empty resource is filled in by the redirect
step; what fails is skipping that step, not creating the type. The other affected types
were not re-measured, so the claim is now marked unverified for them instead of stated
as fact.

**Rounding.** The note that `BasketItem.serialize` does not round (#18) read as a
theoretical hazard. It is not: a three-unit line with `amountVat=15.97 * 3` is enough,
and the API refuses the whole basket with `API.600.200.133 "Amount 47.910000000000004
has more than 4 positions after the decimal point."`
@sveneberth sveneberth added the documentation Improvements or additions to documentation label Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant