Skip to content

docs(setups): use payment method status values from the spec - #222

Merged
rodrigojara-cko merged 4 commits into
masterfrom
feat/INT-1725-payment-setup-shape-gaps
Oct 20, 2026
Merged

rodrigojara-cko merged 4 commits into
masterfrom
feat/INT-1725-payment-setup-shape-gaps

Conversation

@rodrigojara-cko

@rodrigojara-cko rodrigojara-cko commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

Summary

The Blik status doc and the payment method serialization specs used "available", which is not a PaymentMethodStatus value in the Payment Setup spec (unavailable, action_required, ready, initialization_required, invalid). This switches them to "ready" and points the status doc of Blik, Bacs, CardPresent and Stablecoin at PaymentSetupPaymentMethodStatus. No behaviour change: status is a String.

The rest of the Payment Setup shape alignment done in the other SDKs (card details, wallet token object, sub-merchant number_of_sales, settings, auto_confirm, metadata, instrument.type) needs no code change here: create_payment_setup and update_payment_setup take a Hash and send it as is, and the SDK has no typed classes for those shapes. What was missing is the documentation of those keys on the client, added here.

Changes

  • lib/checkout_sdk/payments/setups/blik_payment_method.rb, bacs_payment_method.rb, card_present_payment_method.rb, stablecoin_payment_method.rb: status doc uses a spec value and references PaymentSetupPaymentMethodStatus; Blik maps to its swagger schema.
  • lib/checkout_sdk/payments/setups/payment_setups_client.rb: documents payment_methods.card (token, details), applepay and googlepay (token_data, token as an object), instrument, auto_confirm, settings.capture and excluded_payment_methods, order.sub_merchants[].number_of_sales and metadata on create and update, and the read-only fields returned.
  • spec/checkout_sdk/payments/setups/setup_payment_methods_serialization_spec.rb: 'available' replaced by 'ready' for Bacs, CardPresent, PayByBank and Stablecoin, a valid initialization (enabled) in the Bacs spec, and a new Blik serialization spec.

API Reference

  • POST /payments/setups
  • PUT /payments/setups/{id}
  • GET /payments/setups/{id}
  • POST /payments/setups/{id}/confirm/{payment_method_name}

Breaking changes

None.

README

No change needed.

@agent-wall-e

agent-wall-e Bot commented Oct 15, 2026

Copy link
Copy Markdown

🟢 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 diff contains only a documentation string update and test value corrections from an invalid string to a valid enum value, with no behavioral, structural, or data changes.

Operational gates

  • ✅ jira_ticket (INT-1725)
  • ✅ independent_review

Files analysed: 2


wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

@agent-wall-e

agent-wall-e Bot commented Oct 15, 2026

Copy link
Copy Markdown
🔬 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 diff contains only a documentation string update and test value corrections from an invalid string to a valid enum value, with no behavioral, structural, or data changes. 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

The Blik status doc and the payment-method serialization specs used
"available", which is not a PaymentMethodStatus value. Use "ready" and
point the doc at PaymentSetupPaymentMethodStatus.
@rodrigojara-cko
rodrigojara-cko force-pushed the feat/INT-1725-payment-setup-shape-gaps branch from 2a9a361 to 59e0aa9 Compare October 15, 2026 14:44
@agent-wall-e

agent-wall-e Bot commented Oct 15, 2026

Copy link
Copy Markdown

🟢 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 change is purely a documentation comment update and test string correction ('available' to 'ready') with no behavioral, structural, or data changes—status remains a plain String field with no new endpoints, persisted data, or auth changes.

Operational gates

  • ✅ jira_ticket (INT-1725)
  • ✅ independent_review

Files analysed: 2


wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

@agent-wall-e

agent-wall-e Bot commented Oct 15, 2026

Copy link
Copy Markdown
🔬 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 change is purely a documentation comment update and test string correction ('available' to 'ready') with no behavioral, structural, or data changes—status remains a plain String field with no new endpoints, persisted data, or auth changes. 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 agent-wall-e Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ 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 diff is purely a documentation string update and test fixture string replacement ('available' → 'ready') with no behavioral, structural, or data changes.

wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

Document the status values on Bacs, CardPresent and Stablecoin as on Blik, map Blik to
its swagger schema, add a Blik serialization spec, and use a valid initialization value
(enabled) in the Bacs spec.
@agent-wall-e

agent-wall-e Bot commented Oct 19, 2026

Copy link
Copy Markdown

🟢 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 diff contains only documentation comment updates and test fixture value corrections (changing 'available' to 'ready' and adding a new serialization spec), with no behavioral, logic, auth, persistence, or integration changes.

Operational gates

  • ✅ jira_ticket (INT-1725)
  • ✅ independent_review

Files analysed: 5


wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

@agent-wall-e

agent-wall-e Bot commented Oct 19, 2026

Copy link
Copy Markdown
🔬 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 diff contains only documentation comment updates and test fixture value corrections (changing 'available' to 'ready' and adding a new serialization spec), with no behavioral, logic, auth, persistence, or integration changes. 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 agent-wall-e Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ 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:All changes are doc comment updates and test fixture value corrections (string literals in specs), with no behavioral, logic, auth, persistence, or integration changes.

wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

…t keys

The Payment Setup client takes a Hash and documented only some of its keys. Document
payment_methods card (token and details), applepay and googlepay (token_data and the token
object), instrument and auto_confirm, settings capture and excluded_payment_methods,
order sub_merchants number_of_sales and metadata, plus the read-only fields returned.
@agent-wall-e

agent-wall-e Bot commented Oct 19, 2026

Copy link
Copy Markdown

🟢 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 purely documentation comments and test fixture value corrections (replacing invalid 'available' with valid 'ready'), with no logic, behavior, auth, persistence, new endpoints, or new abstractions introduced.

Operational gates

  • ✅ jira_ticket (INT-1725)
  • ✅ independent_review

Files analysed: 6


wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

@agent-wall-e

agent-wall-e Bot commented Oct 19, 2026

Copy link
Copy Markdown
🔬 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 purely documentation comments and test fixture value corrections (replacing invalid 'available' with valid 'ready'), with no logic, behavior, auth, persistence, new endpoints, or new abstractions introduced. 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 agent-wall-e Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ 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:All changes are purely documentation comments and test value corrections (replacing 'available' with 'ready') with no behavioral, logic, auth, data persistence, or integration changes.

wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

david-ruiz-cko
david-ruiz-cko previously approved these changes Oct 19, 2026
… request keys

Mark the wallet token id as required, add the phone length limits, the uri format of the
redirect URLs, the type of every key, the write-only card and wallet fields, and the
read-only response values (Google Pay schemes, set_instrument).
@agent-wall-e

agent-wall-e Bot commented Oct 20, 2026

Copy link
Copy Markdown

🟢 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 purely documentation comments and test value corrections (replacing invalid 'available' with valid 'ready') with no behavioral, logic, auth, persistence, or integration changes.

Operational gates

  • ✅ jira_ticket (INT-1725)
  • ✅ independent_review

Files analysed: 6


wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

@agent-wall-e

agent-wall-e Bot commented Oct 20, 2026

Copy link
Copy Markdown
🔬 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 purely documentation comments and test value corrections (replacing invalid 'available' with valid 'ready') with no behavioral, logic, auth, persistence, or integration changes. 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

Copy link
Copy Markdown

@agent-wall-e agent-wall-e Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ 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 is purely documentation comments and test value corrections (replacing invalid 'available' with valid 'ready'), with no logic, behavior, auth, data persistence, new endpoints, or external integrations changed.

wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…

@rodrigojara-cko
rodrigojara-cko merged commit 09eba32 into master Oct 20, 2026
5 checks passed
@rodrigojara-cko
rodrigojara-cko deleted the feat/INT-1725-payment-setup-shape-gaps branch October 20, 2026 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants