[rodrigojara-cko]

Summary

PaymentMethods had no PayPal member, so a Payment Setup could not configure PayPal at all. This adds the PayPal payment method and the fields the spec defines on the flattened Klarna, Tabby and stc pay methods, including the read-only action each method now returns directly. The spec defines a different action object per method, so each method gets its own action class, as Cash App, Pay by Bank and Instrument already do.

Changes

• New Paypal/Paypal.php: $user_action, $brand_name (max 127 characters), $shipping_preference and read-only $action.
• New Paypal/PaypalUserAction.php (pay_now, continue) and Paypal/PaypalShippingPreference.php (no_shipping, get_from_file, set_provided_address).
• New Klarna/KlarnaAction.php ($type, $client_token, $session_id), Paypal/PaypalAction.php ($type, $order_id) and Stcpay/StcpayAction.php ($type), with KlarnaActionType (sdk), PaypalActionType (sdk) and StcpayActionType (otp).
• PaymentMethods.php: new $paypal, sent as paypal.
• Klarna/Klarna.php: read-only $action and $iban; $account_holder documented; $payment_method_options deprecated.
• Stcpay/Stcpay.php: read-only $action; $otp documented as write only; $payment_method_options deprecated.
• Tabby/Tabby.php: $payment_types (string[]); $payment_method_options deprecated.
• PaymentSetupFieldsSerializationTest.php: literal wire keys for PayPal, Tabby, Klarna and stc pay requests, roundtrips of PayPal, Klarna, stc pay and Tabby with the spec examples, a response test that maps every returned key to the typed models, and the PayPal and action type values.

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}

Deprecated

• $payment_method_options on Klarna, Stcpay and Tabby (@deprecated). The API removed payment_method_options: it no longer sends it and ignores it on requests. Use $action instead (Tabby has no replacement). It will be removed in the next major version. Requested in review.

Breaking changes

None. Only new classes and properties, and deprecation notices.

README

No change needed.

SonarCloud

The new issues are expected to be the snake_case property name rule (php:S116): the property names are the JSON wire keys, as everywhere else in the SDK. Pending confirmation by someone with Sonar access.

[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:All changes are non-destructive additions of new model classes and properties (PayPal, enum helpers, new fields on existing models) that extend existing abstractions without touching auth, persistence, external integrations, background workers, or trust boundaries.

Operational gates

• ✅ jira_ticket (INT-1729)
• ✅ independent_review

Files analysed: 9

---

_{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 — All changes are non-destructive additions of new model classes and properties (PayPal, enum helpers, new fields on existing models) that extend existing abstractions without touching auth, persistence, external integrations, background workers, or trust boundaries.	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}

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:298>250

Operational gates

• ✅ jira_ticket (INT-1729)
• ✅ independent_review

Files analysed: 14

---

_{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
exceeds_bounded_scope — 298>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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]

🟢 Advisory review: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

Adds PayPal payment method and flattened action/field support for Klarna, Tabby, and stc pay payment setups; the diff matches the PR description and new tests cover serialization roundtrips, literal wire keys, enum values, and response deserialization.

What I checked

• All new PayPal classes (Paypal, PaypalAction, PaypalActionType, PaypalUserAction, PaypalShippingPreference) are internally consistent and match their documented wire values.
• KlarnaAction, StcpayAction, and their ActionType companions follow the same pattern as existing code and are consistent with the PR description.
• The $payment_method_options deprecation on Klarna, Stcpay, and Tabby is additive and backward-compatible since the field is still present.
• Tests verify literal wire keys (no 'pay_pal' camelCase drift), roundtrips for every new property, null-value omission, and enum constant correctness.
• The diff is truncated so the full test file and any serializer registration/mapping code cannot be verified, but based on the pattern of existing code in this codebase this looks consistent.

⚠️ 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}

[sonarqubecloud]

Quality Gate passed

Issues
11 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