[rodrigojara-cko]

Summary

Payment Setup in Ruby gets PaymentSetupPaymentType with the six lowercase values of the specification, documented on create and update. The account funding identification type loses TAX_ID and OTHER, which the API rejects with 422, and the account funding sender gets the reference field of the specification. The confirm integration spec no longer skips every time and asserts the fields of the Payment Setup it returns, and the six account funding sender and recipient fields the spec does not have are deprecated.

Changes

• lib/checkout_sdk/payments/setups/payment_setup_payment_type.rb (new): PaymentSetupPaymentType with REGULAR, RECURRING, MOTO, INSTALLMENT, PAY_LATER, UNSCHEDULED ("regular" ... "unscheduled").
• lib/checkout_sdk/payments/payments.rb: requires the new file.
• lib/checkout_sdk/payments/setups/payment_setups_client.rb: :payment_type documented on create_payment_setup and update_payment_setup. PaymentType is unchanged.
• lib/checkout_sdk/payments/setups/account_funding_transaction_identification_type.rb: TAX_ID and OTHER removed; docs on the remaining values.
• lib/checkout_sdk/payments/setups/account_funding_transaction_identification.rb: one doc entry per attribute against the spec.
• lib/checkout_sdk/payments/setups/account_funding_transaction_sender.rb: new reference attribute (the unique reference for the sender of the payment), sent as account_funding_transaction.sender.reference; first_name, last_name, country_of_birth, nationality and address marked @deprecated; one doc entry per attribute against the spec (description, optionality, date_of_birth format date).
• lib/checkout_sdk/payments/setups/account_funding_transaction_recipient.rb: account_type marked @deprecated; one doc entry per attribute against the spec (description, optionality, first_name and last_name max 50, account_number max 34, date_of_birth format date, address keys and their limits).
• lib/checkout_sdk/payments/setups/bacs_payment_method.rb: one doc block per attribute against the spec, including the initialization values and its default.
• lib/checkout_sdk/payments/setups/bacs_payment_method.rb, lib/checkout_sdk/payments/setups/cash_app_payment_method.rb: the initialization doc says an update replaces the payment methods, so enabled must be sent again to keep a method enabled.
• spec/checkout_sdk/payments/setups/payment_setup_payment_type_serialization_spec.rb (new): the six payment type values on the wire and through create and update, the identification values and fields, the sender reference (wire key, round trip, swagger example), and the deprecated sender and recipient fields, which still serialize under their keys.
• spec/checkout_sdk/payments/setups/setup_payment_methods_serialization_spec.rb: Bacs initialization serialization, and Card Present sent under its literal key.
• spec/checkout_sdk/payments/setups/payment_setups_helper.rb: payment_type uses PaymentSetupPaymentType::REGULAR; helpers that pick a ready method from available_payment_methods or expect payment_method_not_ready.
• spec/checkout_sdk/payments/setups/payment_setups_integration_spec.rb: confirm reads available_payment_methods, confirms a ready method or expects payment_method_not_ready, and asserts id, amount, currency, reference and payment_methods, the Payment Setup fields the confirm call returns, instead of action_id, status, processed_on and _links, which that response does not have.

API Reference

• POST /payments/setups: payment_type, payment_methods, account_funding_transaction
• PUT /payments/setups/{id}
• GET /payments/setups/{id}
• POST /payments/setups/{id}/confirm/{payment_method_name}

Payment type

PaymentSetupPaymentType is additive: PaymentType keeps its values, and a setup created with them is still accepted (the API stores Regular, Recurring, Moto in lowercase). The new type is the only way to send pay_later, which PaymentType does not have; the camel case PayLater that other payment types use is rejected with 422 payment_type_property_invalid.

Deprecated

• AccountFundingTransactionSender#first_name, #last_name, #country_of_birth, #nationality and #address. Not part of the Sender schema of the Payment Setups account funding transaction; the API ignores them on requests. There is no replacement. Will be removed in the next major version.
• AccountFundingTransactionRecipient#account_type. Not part of the Recipient schema of the Payment Setups account funding transaction; the API ignores it on requests. There is no replacement. Will be removed in the next major version.

Breaking changes required by the API

• AccountFundingTransactionIdentificationType::TAX_ID and ::OTHER are removed: the API rejects both values with 422 account_funding_transaction.sender.identification.type_property_invalid.

Follow-ups

• Declaring csv as a runtime dependency (needed from Ruby 3.4, where it is no longer a default gem) is a separate change.

README

No change needed.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:409>250

Operational gates

• ✅ jira_ticket (INT-1738)
• ✅ independent_review

Files analysed: 12

---

_{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 — 409>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 PaymentSetupPaymentType with six lowercase values, removes TAX_ID/OTHER identification types, adds sender.reference, deprecates removed schema fields, and fixes the confirm integration spec to assert correct response fields. The diff is internally consistent and matches the stated intent.

What I checked

• PaymentSetupPaymentType constants are correct lowercase values matching the spec, and the module is properly required in payments.rb.
• Removal of TAX_ID and OTHER from AccountFundingTransactionIdentificationType is a breaking change for existing callers using those constants, but the PR explicitly documents this as required by the API rejecting them with 422.
• The new reference attr_accessor on AccountFundingTransactionSender is correctly placed and the serialization spec verifies round-trip and wire key.
• Integration spec correctly replaces the unconditional skip with a branch that either confirms a ready method or asserts payment_method_not_ready, which is a meaningful improvement in test coverage.
• The assert_response in the confirm integration test now checks id/amount/currency/reference/payment_methods instead of action_id/status/processed_on/_links, which matches the PR's claim that the confirm endpoint does not return those fields.
• BacsPaymentMethod refactoring from a single attr_accessor chain to individual attr_accessors with inline docs is functionally equivalent and the serialization tests confirm the wire format.

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

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:492>250

Operational gates

• ✅ jira_ticket (INT-1738)
• ✅ independent_review

Files analysed: 13

---

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

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:540>250

Operational gates

• ✅ jira_ticket (INT-1738)
• ✅ independent_review

Files analysed: 13

---

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

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:522>250

Operational gates

• ✅ jira_ticket (INT-1738)
• ✅ independent_review

Files analysed: 13

---

_{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 — 522>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}

[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