feat: adding paymentRail to quote account destination

[pengying]

TL;DR

Added optional paymentRail field to the AccountDestination schema to allow specifying the payment rail for transfers.

What changed?

Added a new optional paymentRail field to the AccountDestination schema with:

• Type: string
• Description explaining it must be one of the rails supported by the destination account
• Default behavior where the system selects a rail if not specified
• Example value of "ACH"

How to test?

Test API requests that include the AccountDestination object by:

1. Sending requests with the paymentRail field specified (e.g., "ACH")
2. Sending requests without the paymentRail field to verify default behavior
3. Validating that only supported payment rails are accepted for each destination account

Why make this change?

This change provides users with explicit control over which payment rail to use for transfers, while maintaining backward compatibility by making the field optional and preserving existing default rail selection behavior.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	Mar 19, 2026 0:06am

[pengying]

• feat: adding paymentRail to quote account destination #279 👈 (View in Graphite)
• main

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

[github-actions]

✱ Stainless preview builds

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

kotlin

feat(api): add paymentRail field to AccountDestination in quotes

openapi

feat(api): add paymentRail field to destination account details

python

feat(api): add payment_rail parameter to quote destination

typescript

feat(api): add paymentRail field to quotes account destination

✅ grid-openapi studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅

⚠️ grid-python studio · code

Your SDK build had a failure in the lint CI job, which is a regression from the base state.
generate ✅ → build ✅ → lint ❗ → test ✅

pip install https://pkg.stainless.com/s/grid-python/a27c51cb806840c3ac50b332e176ff756a53b059/grid-0.0.1-py3-none-any.whl

✅ grid-kotlin studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → build ✅ → lint ✅ → test ✅

⚠️ grid-typescript studio · code

Your SDK build had a failure in the lint CI job, which is a regression from the base state.
generate ✅ → build ✅ → lint ❗ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/4414787087f6c12ef1cbf772e7e3afe5fd930cee/dist.tar.gz

---

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-03-19 07:05:12 UTC

[greptile-apps]

Greptile Summary

This PR adds an optional paymentRail field to the AccountDestination schema, giving API consumers explicit control over which payment rail (e.g., ACH, WIRE) to use when creating a quote targeting an external account. The change is backward-compatible — omitting the field preserves the existing default-selection behavior. All three changed files (openapi/components/schemas/quotes/AccountDestination.yaml, openapi.yaml, mintlify/openapi.yaml) are consistent with one another, and the two root YAML files appear to be the expected generated output of make build.

Key observations:

• The field is correctly marked optional (not added to required) and the description clearly explains both the constraint and the default behavior.
• The new singular paymentRail field name is appropriately distinct from the plural paymentRails array on the account info schemas, which list the rails a destination supports.
• The field is typed as a free-form string with no enum constraint. The existing *AccountInfo.yaml schemas define their supported rails as enums (e.g., ACH, WIRE, RTP, FEDNOW for USD). Adding an enum here — or a $ref to a shared PaymentRail schema — would improve spec discoverability and enable client-side validation without a round-trip to the API.

Confidence Score: 4/5

• This PR is safe to merge — the change is a backward-compatible, additive schema field with no breaking impact.
• The change is small, isolated, and additive. The field is correctly optional and the description is clear. The only concern is the lack of an enum constraint on paymentRail, which is a documentation/discoverability issue rather than a functional bug.
• openapi/components/schemas/quotes/AccountDestination.yaml — consider adding an enum constraint to paymentRail

Important Files Changed

Filename	Overview
openapi/components/schemas/quotes/AccountDestination.yaml	Adds optional paymentRail string field to the AccountDestination schema; the field lacks an enum constraint, which limits discoverability of valid values from the spec.
openapi.yaml	Bundled output of make build — mirrors the source change in AccountDestination.yaml; same enum concern applies.
mintlify/openapi.yaml	Mintlify-specific bundled output — identical change to openapi.yaml; generated artifact from make build.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Quote Request with AccountDestination] --> B{paymentRail specified?}
    B -- Yes --> C[Validate rail against destination account's supported rails]
    C --> D{Rail supported?}
    D -- Yes --> E[Create Quote with specified paymentRail]
    D -- No --> F[Error: Unsupported payment rail]
    B -- No --> G[System selects default rail for destination account]
    G --> E

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: openapi/components/schemas/quotes/AccountDestination.yaml
Line: 17-23

Comment:
**No enum constraint on `paymentRail`**

The `paymentRail` field is defined as a free-form `type: string`, but the valid values are well-defined enums in the existing account info schemas. For example, `UsdAccountInfo.yaml` defines `paymentRails` items as an enum: `ACH`, `WIRE`, `RTP`, `FEDNOW`.

Without an enum constraint (or a `$ref` to a shared `PaymentRail` schema), API clients have no way to discover valid values from the spec alone, and invalid values will only be caught at runtime. Consider either:
1. Adding an enum with the superset of all supported rails (e.g., `ACH`, `WIRE`, `RTP`, `FEDNOW`, plus any non-USD rails), or
2. Extracting a shared `PaymentRail` schema and using `$ref` here — the same way `paymentRails` items in each `*AccountInfo.yaml` could reference it.

```suggestion
      paymentRail:
        type: string
        enum:
          - ACH
          - WIRE
          - RTP
          - FEDNOW
        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.
        example: ACH
```
(Adjust the enum values to match all rails supported across all destination account types.)

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

_{Last reviewed commit: "feat: adding payment..."}

[greptile-apps]

No enum constraint on paymentRail

The paymentRail field is defined as a free-form type: string, but the valid values are well-defined enums in the existing account info schemas. For example, UsdAccountInfo.yaml defines paymentRails items as an enum: ACH, WIRE, RTP, FEDNOW.

Without an enum constraint (or a $ref to a shared PaymentRail schema), API clients have no way to discover valid values from the spec alone, and invalid values will only be caught at runtime. Consider either:

1. Adding an enum with the superset of all supported rails (e.g., ACH, WIRE, RTP, FEDNOW, plus any non-USD rails), or
2. Extracting a shared PaymentRail schema and using $ref here — the same way paymentRails items in each *AccountInfo.yaml could reference it.

Suggested change

	paymentRail:
	type: string
	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.
	example: ACH
	paymentRail:
	type: string
	enum:
	- ACH
	- WIRE
	- RTP
	- FEDNOW
	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.
	example: ACH

(Adjust the enum values to match all rails supported across all destination account types.)

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/quotes/AccountDestination.yaml
Line: 17-23

Comment:
**No enum constraint on `paymentRail`**

The `paymentRail` field is defined as a free-form `type: string`, but the valid values are well-defined enums in the existing account info schemas. For example, `UsdAccountInfo.yaml` defines `paymentRails` items as an enum: `ACH`, `WIRE`, `RTP`, `FEDNOW`.

Without an enum constraint (or a `$ref` to a shared `PaymentRail` schema), API clients have no way to discover valid values from the spec alone, and invalid values will only be caught at runtime. Consider either:
1. Adding an enum with the superset of all supported rails (e.g., `ACH`, `WIRE`, `RTP`, `FEDNOW`, plus any non-USD rails), or
2. Extracting a shared `PaymentRail` schema and using `$ref` here — the same way `paymentRails` items in each `*AccountInfo.yaml` could reference it.

```suggestion
      paymentRail:
        type: string
        enum:
          - ACH
          - WIRE
          - RTP
          - FEDNOW
        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.
        example: ACH
```
(Adjust the enum values to match all rails supported across all destination account types.)

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