[rodrigojara-cko]

Summary

Payment Setup returns the next action of each payment method directly on the method (payment_methods.klarna.action, payment_methods.paypal.action, payment_methods.stcpay.action). The Go types did not model it, so GetPaymentSetup dropped it and a merchant could not read the Klarna client token or the PayPal order ID needed to launch those flows. This adds the action and the other fields the spec defines for Klarna, PayPal, Tabby and stc pay.

Changes

• payments/setups/setups.go:
  • PaymentMethodAction: new read-only OrderId (order_id, PayPal). Docs list the type per method (sdk for Klarna and PayPal, otp for stc pay).
  • KlarnaPaymentMethod: read-only Action and Iban.
  • PaypalPaymentMethod: BrandName (max 127 characters), ShippingPreference and read-only Action.
  • New PaypalShippingPreference with PaypalShippingPreferenceNoShipping, PaypalShippingPreferenceGetFromFile and PaypalShippingPreferenceSetProvidedAddress.
  • StcpayPaymentMethod: read-only Action; Otp documented as write only.
  • TabbyPaymentMethod: PaymentTypes ([]string).
• payments/setups/setups_fields_test.go: literal wire keys for the PayPal and Tabby request fields (read-only action not sent when unset), every PaypalShippingPreference value, deserialization of action from Klarna, PayPal and stc pay plus Klarna iban from a response with the spec examples, and a roundtrip of every new property.

API Reference

• POST /payments/setups: payment_methods.paypal.brand_name, payment_methods.paypal.shipping_preference, payment_methods.tabby.payment_types
• PUT /payments/setups/{id}
• GET /payments/setups/{id}
• POST /payments/setups/{id}/confirm/{payment_method_name}

Breaking changes

None. Only new fields and a new type. PaypalPaymentMethod.UserAction stays a string.

README

No change needed.

[agent-wall-e]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:The PR only adds new read-only response fields and optional request fields to existing payment method structs, reusing existing types and endpoints without introducing new endpoints, external integrations, persisted data classes, auth changes, or background processes.

Operational gates

• ✅ jira_ticket (INT-1729)
• ✅ independent_review

Files analysed: 2

---

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

[agent-wall-e]

🔬 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.
2.2.6_logical_extension — The PR only adds new read-only response fields and optional request fields to existing payment method structs, reusing existing types and endpoints without introducing new endpoints, external integrations, persisted data classes, auth changes, or background processes.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

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]

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