Skip to main content

​
New Features

​
Opal Balance Transfer

Customers can now let borrowers specify how much of an approved loan to send to each eligible debt directly within Opal. Balance Transfer adds payment allocation to the flow, allowing customers to support debt consolidation without building their own allocation and validation screens. Customers can create an Opal session with mode: "balance_transfer" and configure the loan amount, payment limits, permitted unallocated amount, and account selection filters. After the borrower confirms their allocations, the customer’s backend retrieves the session and releases payments when funding is ready. Method checks the allocations and accounts again, then attempts to create a Payment for each allocated account. The bt.payment_ids field contains the result of each attempt; an entry can be null if that Payment could not be created. Balance Transfer supports eligible payable liabilities, not only credit cards. It is enabled per team. Customers can contact their Method CSM to configure access and funding details. For more information, visit the Opal Balance Transfer guide and Release Payments reference.

​
Changes

​
Partial Reversal Payment Statuses

Customers reconciling bill-payment returns can now distinguish a partial return from a full reversal, helping their teams and users track exactly how much is being returned. For eligible bill payments that are not consolidated with another Method Payment, the Payment moves through partial_reversal_processing to partially_reversed when a biller returns only part of a delivered payment. The associated Reversal records the amount returned. The payment.update, payment_reversal.create, and payment_reversal.update events track the return. Customers can list a Payment’s Reversals or retrieve a specific Reversal to check its amount and status without treating a partial return as a full refund.
Integrations that handle a fixed list of Payment statuses should add partial_reversal_processing and partially_reversed.
For more information, visit the Payment Lifecycle guide and Reversals documentation.

​
Expired Check Payments

Method now automatically stops eligible paper checks that remain uncashed after five full business days following the day they were sent, reducing manual follow-up on payments that are unlikely to settle. This window excludes weekends and bank holidays. A successful stop is identified by the PAYMENT_STOPPED_EXPIRED (10012) payment error and starts the existing reversal flow, giving operations and support teams a clear outcome and a way to track the return of funds.
This applies to eligible checks still reported as mailed. A resend starts a new five-business-day window. Five days is the eligibility threshold, not a guaranteed stop time. Stopping a check does not make returned funds immediately available.
For more information, visit the Payment Lifecycle guide, Reversals documentation, and Payment Errors reference.

​
Improvements

Customers can now pay eligible Navy Federal credit-card accounts without asking their users to enter or verify an account number, removing an additional step that could otherwise block payment setup. When a supported credit report provides a valid full card number, Method can make the account payable without additional account-number verification. These accounts can be paid electronically where supported; some may still require paper checks. For more information, visit the Payments guide.

​
Surface the Most Up-to-Date Data on Accounts

Customers can ensure linked accounts to reflect the most recent account data, rather than basing it on when an Update was created, helping their users see most current information when direct and snapshot Updates arrive on different schedules. This is particularly useful for Accounts with Update subscriptions, where arrival order does not necessarily reflect data freshness. To select the freshest data_as_of value among an Account’s recent completed Updates, customers can use sort[update]=-data_as_of with expand[]=update when listing or retrieving Accounts:
This option is available on API version 2024-04-04 and later. The default remains sort[update]=-created_at. This parameter selects each Account’s Update; it does not reorder the Accounts in a list.
For more information, visit List all Accounts and Retrieve an Account.

​
Opal Card Selection

Customers can now limit the number of cards their users select in each Opal Card Connect session, allowing the flow to match their platform’s card-linking requirements. Opal Card Connect supports max_selection_count for sessions with selection_type: "multiple". Users can see how many cards they have selected, and Opal prevents further selections when they reach the configured limit. Omitting the parameter allows unlimited selection. Card Connect also shows the specific credit-card product name when it is available, helping users distinguish similar cards. For more information, visit the Opal Card Connect guide.

​
Dashboard Payment and Account Details

Customers’ operations and support teams can now investigate payments, track returned funds, and review their users’ Accounts in one place. The Method Dashboard now includes:
  • Payment confirmation numbers: Completed payments show an available confirmation number in Destination details, giving support teams a reference for an investigation.
  • Reversal details: Payment pages show the Reversal’s amount, direction, status, target account, and available trace information. They also show an estimated completion date when one is available for a Reversal that has not failed.
  • Account pagination: Entity pages let teams page through an Account list and show each entity’s full Account count.

​
Fixes

​
Account List Reliability

Teams can page through large Account lists and report their size correctly. Now, entity-filtered Account lists return accurate total and page counts when an Entity has more than 100 Accounts. They also accept the previous-page cursors returned by the API. Account-list requests now complete when an existing liability Account has no account number. The affected Account returns null for liability.mask and liability.fingerprint instead of causing the entire request to fail, so customers can still retrieve the list and use the other available account details. For more information, visit List all Accounts.

​
Payment Funds Reports

Previously, if a Payment changed during report generation, that Payment may appear more than once in an itemized or summary payment funds report. Now, newly generated reports deduplicate Payments by ID, preventing repeated records from affecting reconciliation. For more information, visit the Reports documentation.

​
Bill Payment Consolidation

Bill payment consolidation combines eligible payments to the same liability into a single payment instruction. Fixed an issue that could prevent consolidation when fees were included. Matching and consolidated amounts now use the amount sent to the destination after fees, avoiding unnecessary retries and delays for affected payments. For more information, visit the Payments documentation.

​
Account Type Classification

Corrected account-type mappings for newly processed credit-report data:
  • Affected collection tradelines now use the collection account type instead of a generic loan type.
  • Manufactured-housing accounts in affected report formats now map to mortgages.
  • Additional credit-report codes now distinguish mortgages, credit-builder accounts, credit cards, and other loans for affected records.
Teams can use the corrected types when displaying newly processed Accounts and applying eligibility rules. For more information, visit the Accounts documentation.

​
Payment Webhook Notifications

Fixed a case where an internal payment-status change could send a payment.update webhook even though the customer-visible Payment had not changed. This reduces notifications that require processing but contain no public resource change. For more information, visit the Webhooks documentation.