Skip to content

feat(transfers): allow selecting payment rail on transfer-out destination#533

Open
pengying wants to merge 1 commit into
mainfrom
feat-transfer-out-payment-rail
Open

feat(transfers): allow selecting payment rail on transfer-out destination#533
pengying wants to merge 1 commit into
mainfrom
feat-transfer-out-payment-rail

Conversation

@pengying
Copy link
Copy Markdown
Contributor

@pengying pengying commented May 30, 2026

What

Adds an optional paymentRail field to the transfer-out destination, mirroring the rail selection already available on quote destinations.

Changes

  • New TransferOutDestination schema (accountId + optional paymentRail) — used only by transfer-out, so the shared ExternalAccountReference (transfer-in source) is left unchanged.
  • TransferOutRequest.destination now references the new schema.
  • paymentRail reuses the common PaymentRail enum (ACH, SEPA, PIX, WIRE, …); when omitted, the system selects a default rail.
  • Added paymentRail: ACH to the transfer-out request example.
  • Rebundled openapi.yaml + mintlify/openapi.yaml.

Verification

  • make build + make lint pass with 0 errors.

🤖 Generated with Claude Code

@vercel
Copy link
Copy Markdown

vercel Bot commented May 30, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
grid-flow-builder Ignored Ignored Preview May 30, 2026 12:44am

Request Review

Copy link
Copy Markdown
Contributor Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

@pengying pengying marked this pull request as ready for review May 30, 2026 00:37
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 30, 2026

✱ Stainless preview builds for grid

This PR will update the grid SDKs with the following commit messages.

cli

feat(transfers): allow selecting payment rail on transfer-out destination

csharp

feat(transfers): allow selecting payment rail on transfer-out destination

go

feat(transfers): allow selecting payment rail on transfer-out destination

kotlin

feat(transfers): allow selecting payment rail on transfer-out destination

openapi

feat(transfers): allow selecting payment rail on transfer-out destination

php

feat(transfers): allow selecting payment rail on transfer-out destination

python

feat(transfers): allow selecting payment rail on transfer-out destination

ruby

feat(transfers): allow selecting payment rail on transfer-out destination

typescript

feat(transfers): allow selecting payment rail on transfer-out destination

Edit this comment to update them. They will appear in their respective SDK's changelogs.

grid-openapi studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅

New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
grid-ruby studio · code · diff

Your SDK build had at least one "note" diagnostic, which is a regression from the base state.
generate ✅build ✅lint ✅test ✅

New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
grid-kotlin studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅build ✅lint ✅test ✅

New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
grid-typescript studio · code · diff

Your SDK build had at least one "note" diagnostic, which is a regression from the base state.
generate ✅build ✅lint ✅test ✅

npm install https://pkg.stainless.com/s/grid-typescript/d92b58810ccee42e81ff554bb084648634846f37/dist.tar.gz
New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
grid-python studio · code · diff

Your SDK build had at least one "note" diagnostic, which is a regression from the base state.
generate ✅build ✅lint ❗test ❗

pip install https://pkg.stainless.com/s/grid-python/9429c670a3ce175abc8e6b0e1b1360b18821b496/grid-0.0.1-py3-none-any.whl
New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
grid-csharp studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️build ❗lint ✅test ❗

New diagnostics (2 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
💡 Name/Renamed: 247 names were renamed due to language constraints, so fallback names will be used instead.
grid-go studio · code · diff

Your SDK build had at least one "note" diagnostic, which is a regression from the base state.
generate ✅build ✅lint ❗test ❗

go get github.com/stainless-sdks/grid-go@a5f180c6ca9953b20f476031c9e4175dbf2fd8e1
New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
grid-php studio · code · diff

Your SDK build had at least one "note" diagnostic, which is a regression from the base state.
generate ✅lint ✅test ✅

New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`
grid-cli studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ⚠️build ❗lint ❗test ❗

New diagnostics (1 note)
💡 Model/Recommended: We recommend you use a model for `#/components/schemas/ExternalAccountDestinationReference`

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-05-30 00:49:48 UTC

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 30, 2026

Greptile Summary

This PR introduces a dedicated TransferOutDestination schema that extends the existing accountId-only ExternalAccountReference with an optional paymentRail field, then wires it into TransferOutRequest. The bundled openapi.yaml and mintlify/openapi.yaml are both regenerated correctly.

  • New TransferOutDestination schema — keeps the shared ExternalAccountReference (used by transfer-in source) untouched and adds an optional paymentRail property that references the common PaymentRail enum; when omitted, the system picks a default rail.
  • TransferOutRequest.destination — now points at TransferOutDestination instead of ExternalAccountReference, making the rail-selection capability available on transfer-out requests.
  • Example updatedtransfer_out.yaml request example includes paymentRail: ACH to illustrate the new field.

Confidence Score: 4/5

Safe to merge — the change is additive (optional field only) and the shared ExternalAccountReference schema used elsewhere is left untouched.

The new TransferOutDestination schema is minimal and correct. The only noteworthy item is a style inconsistency in how the paymentRail description is positioned relative to allOf compared to the identical field in AccountDestination.yaml, which won't affect runtime behavior but is worth aligning for doc-rendering consistency.

openapi/components/schemas/transfers/TransferOutDestination.yaml — minor description placement inconsistency worth a quick look before merging.

Important Files Changed

Filename Overview
openapi/components/schemas/transfers/TransferOutDestination.yaml New schema for transfer-out destination; paymentRail is optional and correctly references the shared PaymentRail enum, but description placement differs from the existing AccountDestination.yaml pattern.
openapi/components/schemas/transfers/TransferOutRequest.yaml Switches destination ref from ExternalAccountReference to the new TransferOutDestination; the description sibling-to-$ref pattern was already present before this PR.
openapi/paths/transfers/transfer_out.yaml Adds paymentRail: ACH to the request example — straightforward and consistent with the schema change.
openapi.yaml Bundled output correctly reflecting the new TransferOutDestination schema and updated TransferOutRequest.
mintlify/openapi.yaml Mintlify bundled output matches openapi.yaml changes; no divergence detected.

Sequence Diagram

sequenceDiagram
    participant Client
    participant API as Grid API
    participant Validator as Schema Validator
    participant Rails as Payment Rail Selector

    Client->>API: POST /transfers/transfer-out
    Note over Client,API: { source: { accountId }, destination: { accountId, paymentRail? }, amount }
    API->>Validator: Validate TransferOutRequest
    Validator->>Validator: Check TransferOutDestination schema
    alt paymentRail provided
        Validator-->>API: Valid (e.g. paymentRail: ACH)
        API->>Rails: Use specified rail
    else paymentRail omitted
        Validator-->>API: Valid (field optional)
        API->>Rails: Select default rail for account
    end
    Rails-->>API: Rail confirmed
    API-->>Client: 201 Created (transfer initiated)
Loading

Fix All in Claude Code

Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
openapi/components/schemas/transfers/TransferOutDestination.yaml:9-15
The `description` placement for `paymentRail` is inconsistent with the equivalent field in `AccountDestination.yaml`. There, the description lives **inside** the `allOf` array as a second schema object (`- description: ...`), while here it sits as a sibling to `allOf`. Both are valid OpenAPI 3.0, but for consistency with the established pattern in the codebase the description should move inside the array.

```suggestion
  paymentRail:
    allOf:
      - $ref: ../common/PaymentRail.yaml
      - description: >-
          The payment rail to use for the transfer. Must be one of the rails
          supported by the destination account. If not specified, the system
          will select a default rail.
```

Reviews (1): Last reviewed commit: "feat(transfers): allow selecting payment..." | Re-trigger Greptile

Comment on lines +9 to +15
paymentRail:
description: >-
The payment rail to use for the transfer. Must be one of the rails
supported by the destination account. If not specified, the system
will select a default rail.
allOf:
- $ref: ../common/PaymentRail.yaml
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

P2 The description placement for paymentRail is inconsistent with the equivalent field in AccountDestination.yaml. There, the description lives inside the allOf array as a second schema object (- description: ...), while here it sits as a sibling to allOf. Both are valid OpenAPI 3.0, but for consistency with the established pattern in the codebase the description should move inside the array.

Suggested change
paymentRail:
description: >-
The payment rail to use for the transfer. Must be one of the rails
supported by the destination account. If not specified, the system
will select a default rail.
allOf:
- $ref: ../common/PaymentRail.yaml
paymentRail:
allOf:
- $ref: ../common/PaymentRail.yaml
- description: >-
The payment rail to use for the transfer. Must be one of the rails
supported by the destination account. If not specified, the system
will select a default rail.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/transfers/TransferOutDestination.yaml
Line: 9-15

Comment:
The `description` placement for `paymentRail` is inconsistent with the equivalent field in `AccountDestination.yaml`. There, the description lives **inside** the `allOf` array as a second schema object (`- description: ...`), while here it sits as a sibling to `allOf`. Both are valid OpenAPI 3.0, but for consistency with the established pattern in the codebase the description should move inside the array.

```suggestion
  paymentRail:
    allOf:
      - $ref: ../common/PaymentRail.yaml
      - description: >-
          The payment rail to use for the transfer. Must be one of the rails
          supported by the destination account. If not specified, the system
          will select a default rail.
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Fix in Claude Code

…tion

Add an optional `paymentRail` field to the transfer-out destination,
mirroring the rail selection already available on quote destinations.
Introduces a dedicated `ExternalAccountDestinationReference` schema
(accountId + paymentRail) so the shared `ExternalAccountReference` used by
transfer-in is left unchanged. The field reuses the common `PaymentRail` enum.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@pengying pengying force-pushed the feat-transfer-out-payment-rail branch from 2fdb748 to 4088263 Compare May 30, 2026 00:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant