feat(setups): add klarna and stcpay actions, tamara fields, payment type by rodrigojara-cko · Pull Request #258 · checkout/checkout-sdk-python

rodrigojara-cko · 2026-10-26T14:21:13Z

Summary

Payment Setup in Python gains Klarna iban and action, stc pay action, and Tamara initialization and risk_assessment. payment_type gets its own enum with the six lowercase spec values (PaymentType.PAYLATER sends PayLater, which the API rejects with 422), local_date_time is typed as a date-time and last_payment_amount as a number. Members not in the spec are marked deprecated, except card_present, which the API supports. Every payment method keeps the base class it had before, and PaymentType can still be imported from the setups module.

Changes

checkout_sdk/payments/setups/setups.py:
- PaymentSetupPaymentType (REGULAR, RECURRING, MOTO, INSTALLMENT, PAY_LATER, UNSCHEDULED) on PaymentSetupsRequest.payment_type; the payments PaymentType is unchanged.
- PaymentType is still imported in the setups module (marked # noqa: F401 with a deprecation comment pointing to PaymentSetupPaymentType), so from checkout_sdk.payments.setups.setups import PaymentType keeps working.
- Klarna.iban, Klarna.action (KlarnaAction, KlarnaActionType), Stcpay.action (StcpayAction, StcpayActionType).
- Tamara keeps its base class PaymentSetupPaymentMethod and declares initialization itself (default disabled), plus risk_assessment (TamaraRiskAssessment).
- Bizum and Blik keep their base class PaymentMethodBase. Each one redeclares initialization with the same type and default and a deprecation comment, so callers and the request body do not change.
- PaymentSetupTerminal.local_date_time is datetime (a string is still sent unchanged); MerchantAccount.last_payment_amount is float.
- The initialization doc (PaymentMethodBase and Tamara) says that an update replaces the payment methods, so enabled must be sent again to keep a method enabled; the specification does not state this, it is the API's behaviour.
- The docs of Ideal.description, Knet.language and Bancontact.account_holder_name say that the specification marks them optional, but the API keeps the method invalid until they are sent.
- Blik.partner_code is documented as writeOnly, as in the spec.
- Deprecation comments on the members listed under Deprecated.
tests/payments/setups/payment_setups_serialization_test.py: literal wire keys, round trips through the response wrapper for every new field and the spec examples, every PaymentSetupPaymentType value, local_date_time as datetime and string, last_payment_amount 55.99, deprecated members still sent, the base classes of Bizum, Blik and Tamara, the PaymentType import from the setups module, the deprecated PaymentMethodAction.client_token and session_id still sent and read under their keys, and round trips for Blik.partner_code, Tabby.payment_types and Ideal.description with their spec examples, Knet.language with both values and Bancontact.account_holder_name with a sample name (the spec has no example for those two).
tests/payments/setups/payment_setups_integration_test.py: uses PaymentSetupPaymentType, and the create and get tests compare the response payment_type with the request value directly instead of lowercasing both.

API Reference

Deprecated

All of them will be removed in the next major version.

initialization on Bizum and Blik. Not part of their schemas in the Payment Setups specification. No replacement.
payment_method_options on Klarna, Stcpay, Tabby and Bizum, and the PaymentMethodOptions and PaymentMethodOption classes. Use action on Klarna and stc pay; no replacement on Tabby and Bizum.
PaymentSetupInstrument.phone, account_holder and allow_update. Removed from the Payment Setups specification; the API accepts and ignores them. No replacement.
PaymentMethodAction.client_token and session_id. Not part of the PayPal or instrument action schemas. For Klarna use Klarna.action (KlarnaAction); no replacement for PayPal and instrument.
PaymentType imported from checkout_sdk.payments.setups.setups. Use PaymentSetupPaymentType for Payment Setups; PaymentType stays in checkout_sdk.payments.payments for /payments.

Breaking changes

No class changes its base class and no import is removed.

Default change: Tamara now sends "initialization": "disabled" by default (main sent {}). Harmless: an update replaces the payment methods, so omitting it also leaves Tamara disabled. Migration: set initialization to PaymentMethodInitialization.ENABLED to enable Tamara.
Annotations change (payment_type, local_date_time, last_payment_amount), but Python does not enforce them and existing values are still sent as before. For payment_type, a PaymentType value keeps being sent as is: Regular is accepted, while PayLater keeps getting the 422 from the API, so code that sets PaymentType.PAYLATER should switch to PaymentSetupPaymentType.PAY_LATER. Responses read payment_type as the lowercase string, which compares equal to the PaymentSetupPaymentType value.

Follow-ups

Reported internally:

Order items and shipping keep the /payments types until the next major version.

README

No change needed.

agent-wall-e · 2026-10-26T14:21:19Z

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

no_low_class_matched
prod_source_modified

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 3

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-26T14:21:20Z

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
`no_low_class_matched`	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
`prod_source_modified`	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

classifying — this rule contributed to the chosen tier.
informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

Adds Klarna iban and action, stc pay action and the Tamara fields; payment_type gets its own enum with the six lowercase spec values; local_date_time and last_payment_amount follow the spec types. Members the spec does not have are deprecated.

agent-wall-e · 2026-10-27T10:48:59Z

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

no_low_class_matched
prod_source_modified

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 3

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T10:49:00Z

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
`no_low_class_matched`	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
`prod_source_modified`	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

classifying — this rule contributed to the chosen tier.
informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

agent-wall-e · 2026-10-27T10:49:09Z

🟠 Advisory review: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

The PR adds Klarna/stcpay actions, Tamara fields, and a new PaymentSetupPaymentType enum to the payment setups module, with matching serialization and integration tests. One concrete bug is visible in the truncated test diff: read.action.client_token == actio — this looks like a truncated identifier (action → actio) which would be a NameError at runtime.

Concerns

In payment_setups_serialization_test.py, the assertion read.action.client_token == actio appears to reference an undefined name actio (truncated from action), which would raise a NameError when the test runs — the diff is truncated so this cannot be confirmed as intentional, but it reads as a bug.
The diff is explicitly truncated, so the full content of setups.py (particularly the Stcpay, Tamara, TamaraRiskAssessment, Bizum, Blik, and PaymentSetupPaymentMethod class bodies, and the PaymentSetupsRequest.payment_type annotation change) cannot be verified against the PR description's claims.
The integration test changes assert str(response.payment_type).lower() == request.payment_type.lower() to assert response.payment_type == request.payment_type, which relies on the API returning lowercase payment_type values that compare equal to PaymentSetupPaymentType enum members — this is reasonable given str, Enum inheritance but cannot be fully verified without seeing the response deserialization logic.
The PR description states PaymentSetupPaymentType.PAY_LATER sends pay_later but claims the API rejects PayLater with 422 — the new enum value PAY_LATER = 'pay_later' may also be rejected if the API expects paylater without the underscore; this is not verifiable from the diff alone but is worth confirming against the live API spec.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

agent-wall-e

✅ Auto-approved — this PR meets all Low-risk criteria.

All checks passed, no unresolved comments, and the change classification is:

no_low_class_matched
prod_source_modified
2.2.6_logical_extension:The PR adds new enum values, new fields, and new nested classes purely as natural extensions of existing payment setup abstractions without introducing new endpoints, external integrations, persisted data classes, auth changes, or background workers.

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

The specification types last_payment_amount as a number (example 55.99), but the sandbox stores and returns 55 for 55.99. The doc says so, so the type is not changed back and forth; the specification is reported separately.

agent-wall-e · 2026-10-27T11:14:12Z

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

no_low_class_matched
prod_source_modified

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 3

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T11:14:13Z

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
`no_low_class_matched`	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
`prod_source_modified`	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

classifying — this rule contributed to the chosen tier.
informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

agent-wall-e · 2026-10-27T12:42:21Z

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

no_low_class_matched
prod_source_modified

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 3

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T12:42:22Z

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
`no_low_class_matched`	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
`prod_source_modified`	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

classifying — this rule contributed to the chosen tier.
informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

agent-wall-e · 2026-10-27T14:02:49Z

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

no_low_class_matched
prod_source_modified

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 3

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T14:02:50Z

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
`no_low_class_matched`	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
`prod_source_modified`	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

classifying — this rule contributed to the chosen tier.
informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

agent-wall-e · 2026-10-27T15:35:31Z

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

no_low_class_matched
prod_source_modified

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 3

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T15:35:32Z

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
`no_low_class_matched`	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
`prod_source_modified`	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

classifying — this rule contributed to the chosen tier.
informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

agent-wall-e · 2026-10-29T13:37:42Z

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

no_low_class_matched
prod_source_modified

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 3

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-29T13:37:43Z

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
`no_low_class_matched`	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
`prod_source_modified`	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

classifying — this rule contributed to the chosen tier.
informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

sonarqubecloud · 2026-10-29T13:38:11Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

rodrigojara-cko requested a review from a team October 26, 2026 14:21

rodrigojara-cko added 2 commits October 27, 2026 10:54

fix(setups): keep the original method bases and the PaymentType import

8470818

rodrigojara-cko force-pushed the feat/INT-1738-payment-setup-gaps branch from 338c986 to 8470818 Compare October 27, 2026 10:48

agent-wall-e Bot approved these changes Oct 27, 2026

View reviewed changes

deprecate(setups): PaymentMethodAction client_token and session_id

4791c43

rodrigojara-cko added 2 commits October 27, 2026 14:25

fix(setups): keep card_present undeprecated as on main

44df480

docs(setups): note that an update replaces the payment methods

6fe66a4

docs(setups): note the ideal, knet and bancontact fields the API needs

c7104af

rodrigojara-cko added 2 commits October 29, 2026 12:59

docs(setups): keep only the spec fact in unproven deprecation notes

62c33ca

test(setups): round trip blik, tabby, ideal, knet and bancontact fields

9a38cdf

david-ruiz-cko approved these changes Oct 29, 2026

View reviewed changes

rodrigojara-cko merged commit 39a0bb7 into main Oct 30, 2026
4 checks passed

rodrigojara-cko deleted the feat/INT-1738-payment-setup-gaps branch October 30, 2026 06:49

Conversation

rodrigojara-cko commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🟠 Advisory review: Concerns worth a look

Concerns

Uh oh!

agent-wall-e Bot left a comment

Choose a reason for hiding this comment

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 29, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 29, 2026

Uh oh!

sonarqubecloud Bot commented Oct 29, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

rodrigojara-cko commented Oct 26, 2026 •

edited

Loading

agent-wall-e Bot commented Oct 27, 2026 •

edited

Loading