fix: sync PaymentMethodsType enum with Flow API spec

[armando-rodriguez-cko]

Summary

• Adds 26 payment methods that were missing from PaymentMethodsType (alipay_cn, alipay_hk, alma, benefit, bizum, dana, gcash, kakaopay, klarna, mbway, mobilepay, octopus, paynow, plaid, qpay, remember_me, sepa, stcpay, stored_card, tabby, tamara, tng, truemoney, twint, vipps, wechatpay), keeping the enum in sync with the Flow API's enabled_payment_methods / disabled_payment_methods values.
• Marks giropay and sofort as @deprecated since they are no longer part of the specification, without removing them (backward compatibility).

Fixes #338

Test plan

• No existing tests reference PaymentMethodsType, no test changes needed
• composer lint / code sniffer already run clean on commit

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:lib/Checkout/Payments/Sessions/PaymentMethodsType.php

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{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
security_sensitive_path — lib/Checkout/Payments/Sessions/PaymentMethodsType.php	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

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: Concerns worth a look

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

Adds 26 missing payment method constants and deprecates giropay/sofort, but all properties are instance variables rather than constants, which is inconsistent with how enum-like classes should work and may break callers that reference them statically.

Concerns

• All properties (including both old and new ones) are declared as public $FIELD instance variables, not const FIELD class constants — this means they cannot be referenced as PaymentMethodsType::CARD and require instantiation, which is an unusual and likely unintended pattern for an enum-style class; the diff does not change this but adds 26 more instance variables following the same pattern.
• The REMEMBER_ME entry includes an unusual inline comment warning against disabling it en masse, but this reasoning is embedded in source code rather than documentation, and it is unclear whether this represents actual API behaviour or author opinion that could mislead integrators.
• The alphabetical ordering is broken after the @deprecated GIROPAY block: GCASH appears after GIROPAY rather than before it (G-C < G-I), which is inconsistent with the otherwise alphabetical layout and may cause confusion during future maintenance.
• The PR description claims composer lint runs clean, but there is no CI output visible in the diff to verify this, and the non-const property declarations may trigger sniff rules depending on the ruleset.

---

_{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]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:lib/Checkout/Payments/Sessions/PaymentMethodsType.php

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{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
security_sensitive_path — lib/Checkout/Payments/Sessions/PaymentMethodsType.php	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

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: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:lib/Checkout/Payments/Sessions/PaymentMethodsType.php

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{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
security_sensitive_path — lib/Checkout/Payments/Sessions/PaymentMethodsType.php	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

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 failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE