Skip to content

Conversation

@ShreyaThapa
Copy link
Contributor

  1. Fix Bank Balance Response Missing Fields
  • Added required arrays to oneOf schemas in retrieveFundingSourceBalance.yml to fix Zod union discrimination. Without required fields, the validator always matched the first schema, causing available and closing fields to be dropped from Bank Balance responses.
  1. Added Gram folder
  • Add a /gram folder that houses the overlay.yml and generate openapi.yml file used in Gram MCP
  • When generating the gram/openapi.yml file, use the following Speakeasy CLI command:
  • speakeasy overlay apply --overlay=gram/overlay.yml --schema=openapi.yml --out=gram/openapi.yml
  1. Fix Funding Source Creation Validation Errors in TS SDK
  • Fixed verified field definition in CreateCustomerFundingSource.yml to prevent Speakeasy from generating it as a required field. This allows the Zod union to correctly match the account-numbers schema when creating funding sources with routing/account numbers.

@ShreyaThapa ShreyaThapa changed the title Dev 1807: Validate issue with balance response and make bug fix Dev 1807: Validate issue with balance response and apply fix Nov 12, 2025
gram/overlay.yml Outdated
- Customer must exist (use get_customer or list_customers to verify if needed)
- Choose appropriate funding source creation method based on available data:
* Use account/routing numbers for traditional manual entry
* Use Plaid token if bank account was verified through Plaid
Copy link
Member

Choose a reason for hiding this comment

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

Should remove plaidToken as an option for this request since it will likely be deprecated at some point in favor of the exchange solution?

gram/overlay.yml Outdated
- Choose appropriate funding source creation method based on available data:
* Use account/routing numbers for traditional manual entry
* Use Plaid token if bank account was verified through Plaid
* Use exchange resource if bank was connected via IAV (Instant Account Verification)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* Use exchange resource if bank was connected via IAV (Instant Account Verification)
* Use exchange resource if bank was connected via Instant Account Verification (IAV) through an Open Banking provider (e.g. Plaid, MX, Finicity, Flinks)

gram/overlay.yml Outdated
* Use account/routing numbers for traditional manual entry
* Use Plaid token if bank account was verified through Plaid
* Use exchange resource if bank was connected via IAV (Instant Account Verification)
* Use virtual account type for creating Virtual Account Numbers (VANs) for receiving funds
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* Use virtual account type for creating Virtual Account Numbers (VANs) for receiving funds
* Use virtual account type for creating Virtual Account Numbers (VANs) for enabling ACH transactions to and from a Dwolla Balance (digital wallet)

gram/overlay.yml Outdated
<workflow>
1. Determine which funding source creation method to use based on available data
2. For traditional method: Obtain valid US routing number and account number
3. For Plaid method: First obtain a Plaid processor token
Copy link
Member

Choose a reason for hiding this comment

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

Similar comment as above. Should we remove plaidToken reference?

gram/overlay.yml Outdated
* Use Plaid token if bank account was verified through Plaid
* Use exchange resource if bank was connected via IAV (Instant Account Verification)
* Use virtual account type for creating Virtual Account Numbers (VANs) for receiving funds
- Ensure customer type supports the chosen funding source method
Copy link
Member

Choose a reason for hiding this comment

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

Any additional context we can provide here with what we mean by this bullet point?

gram/overlay.yml Outdated
1. Determine which funding source creation method to use based on available data
2. For traditional method: Obtain valid US routing number and account number
3. For Plaid method: First obtain a Plaid processor token
4. For exchange method: First create an exchange session and obtain exchange resource
Copy link
Member

Choose a reason for hiding this comment

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

Exchange session isn't always required in order to create a funding source.

gram/overlay.yml Outdated
2. For traditional method: Obtain valid US routing number and account number
3. For Plaid method: First obtain a Plaid processor token
4. For exchange method: First create an exchange session and obtain exchange resource
5. Specify bank account type (checking, savings, or for VANs: checking only)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
5. Specify bank account type (checking, savings, or for VANs: checking only)
5. Specify bank account type (checking, savings, or for VANs: virtual)

gram/overlay.yml Outdated
Instant Account Verification (IAV) partners like MX, Plaid, or Finicity.
</context>
<when_to_use>
- Customer connected their bank through Dwolla's Open Banking flow
Copy link
Member

Choose a reason for hiding this comment

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

Should we include the secure token exchange solution here? These bullets seem to lean towards our Open Banking solution that uses exchange sessions and exchanges.

gram/overlay.yml Outdated
- Create an exchange session first (use exchange partner integration)
- Customer must complete the bank connection through IAV flow
- Obtain the exchange resource URL from the successful connection
- Use list_available_connections to see which banks were connected
Copy link
Member

Choose a reason for hiding this comment

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

This endpoint/tool is pretty complex which in turn makes it difficult to bullet point pre-requisites. Maybe we should think about this more broadly to start? TLDR; wonder if we should remove this bullet point

<prerequisites>
- Customer must be a verified customer with Dwolla Balance access
- Virtual account type must be set to "virtual"
- Bank account type must be "checking" (only supported type for VANs)
Copy link
Member

Choose a reason for hiding this comment

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

Should this be virtual?

Copy link
Member

@spencerhunter spencerhunter left a comment

Choose a reason for hiding this comment

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

@ShreyaThapa A few recommendations are ready for review!

@ShreyaThapa ShreyaThapa merged commit 0665d40 into main Nov 14, 2025
4 checks passed
@ShreyaThapa ShreyaThapa deleted the DEV-1807 branch November 14, 2025 16:25
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.

3 participants