Skip to content

Correct two documented claims that measurement contradicts #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sveneberth wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

Correct two documented claims that measurement contradicts #19

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 22 additions & 5 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,11 +128,23 @@ the UI components; only the resulting `typeId` comes back to the backend, so a s
`createPaymentType()` with an empty body never occurs in those flows. For `Card` it is doubly
deliberate: accepting raw card data would make the integration PCI-DSS liable.

This has a consequence for testing: **these types cannot be exercised server-side.** Creating
one yields an empty resource that the provider rejects further down the flow — Klarna answers
`COR.800.400.160 "Validation error at partner system"`, which looks like an SDK bug and is not
one. The sandbox tests therefore only drive types whose fields the SDK actually sends (SEPA
direct debit, EPS, the paylater types, Wero, Direct Bank Transfer).
This has a consequence for testing, but a narrower one than previously written here.
Creating such a type server-side yields an empty resource, and the provider may reject it
further down the flow — Klarna has been seen answering `COR.800.400.160 "Validation error
at partner system"`, which looks like an SDK bug and is not one.

**Klarna, measured, does work server-side when the flow is completed.** A
`createPaymentType(Klarna())` with an empty body, an `authorize` carrying `customerId`,
`basketId` and a `returnUrl`, and the customer confirming on the Klarna page the returned
`redirectUrl` leads to, ends with the payment reporting `authorize: success` for the full
amount. So the empty resource is *filled in* by the redirect step, and what fails is
skipping that step, not creating the type. The other affected types — Card, PayPal, Apple
Pay, Google Pay, iDEAL, Click to Pay — were not re-measured; treat the blanket claim as
unverified for them rather than as established.

The sandbox tests still only drive types whose fields the SDK actually sends (SEPA direct
debit, EPS, the paylater types, Wero, Direct Bank Transfer), because the redirect step needs
a browser and would place a real order on every run.

Do not add fields to these classes. Server-side fields belong only to types that are actually
created server-side — Installment, SEPA Direct Debit, Direct Bank Transfer.
Expand Down Expand Up @@ -196,6 +208,11 @@ four decimals (`"5.5500"`).
not a design decision (#18), and it matters most where v3 reconciles the total against the
items to the cent.

It is not a theoretical hazard: building a three-unit line with `amountVat=15.97 * 3` is
enough. The API refuses the basket outright with
`API.600.200.133 "Amount 47.910000000000004 has more than 4 positions after the decimal
point."` — so until #18 is fixed, a caller has to round every item amount itself.

**`Basket` intentionally supports two incompatible schemas.** v1 uses `amountTotalGross`, v3
uses `totalValueGross`; setting the latter switches the basket to the v3 endpoint. Do not
"clean this up" into one schema.
Expand Down
15 changes: 10 additions & 5 deletions tests/sandbox/test_live_api.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,11 +9,16 @@

**What cannot be tested here.** Several payment types are created client-side, by the
Payment Page or the UI components: the browser collects the data and only the resulting
``typeId`` reaches the backend. Creating such a type server-side yields an empty
resource that the payment provider then rejects -- an attempt with Klarna returns
``COR.800.400.160 "Validation error at partner system"``, which looks like an SDK bug
but is not one. Affected: Card, Klarna, PayPal, Apple Pay, Google Pay, iDEAL,
Click to Pay. Only types whose fields the SDK actually sends are exercised below.
``typeId`` reaches the backend. Creating such a type server-side yields an empty resource,
and skipping the browser step can make the provider reject it -- Klarna has been seen
answering ``COR.800.400.160 "Validation error at partner system"``, which looks like an SDK
bug but is not one. Affected: Card, Klarna, PayPal, Apple Pay, Google Pay, iDEAL,
Click to Pay.

Klarna is the one that was followed through: created server-side, authorized, and confirmed
by the customer on the redirect page, the payment reports ``authorize: success``. It is
still not driven here, because that step needs a browser and places a real order on every
run. Only types whose fields the SDK actually sends are exercised below.

**Sandbox accounts differ** in which methods they have enabled, so each test checks
``keypair/types`` first and skips what the account cannot do.
Expand Down
Loading