> ## Documentation Index > Fetch the complete documentation index at: https://docs.methodfi.com/llms.txt > Use this file to discover all available pages before exploring further. # September Updates ## New Features ### Mutual TLS for Webhook Delivery For teams with certificate-based security requirements, Method can now present a client certificate when it delivers webhook events, so your endpoint can confirm that each connection really comes from Method before accepting it. Webhook mTLS works alongside the existing `Authorization` header and HMAC signature checks. Previously, [mTLS](/reference/mtls) was only available for requests sent to Method, not for webhooks Method sends to you. Teams can now use certificate-based authentication in both directions. Webhook mTLS is optional and provisioned per team. Existing webhook endpoints are unaffected. Contact your Method CSM to enable it and receive the certificate details and issuing CA chain for your trust store. For more information, visit the [Webhooks](/reference/webhooks/overview) documentation. ### Signed Message-Level Encryption Method now supports signed MLE for teams that need to verify the authenticity of encrypted API messages. With signed MLE enabled, each payload is signed before encryption, allowing teams to verify that encrypted responses were produced by Method. When enabled, the same requirement applies to inbound traffic: requests sent to Method must also be signed in addition to being encrypted, allowing Method to verify the sender before processing them. This adds message authenticity to existing end-to-end encryption and helps teams meet security controls that require both confidentiality and sender verification. Signed MLE is optional and enabled per team. Contact your Method CSM to enable it. For more information, visit the [Message-Level Encryption](/reference/message-level-encryption#signed-message-level-encryption) documentation. ### Spanish-Language Opal Opal can now support localized experiences (for example, Spanish) through the same integration. The flow can detect the user's browser language automatically or receive an explicit `locale` through the Opal JavaScript SDK. This lets teams serve users in their preferred language without building separate flows for each locale. Localization is currently available in a limited customer implementation. Setting the locale alone does not enable it. Contact your Method CSM to learn more. For more information about building with Opal, visit the [Opal](/opal/overview) documentation. ## Improvements ### Newest-First List Results Paginated list endpoints now return the most recently created resources first by default on API version `2026-03-30` and later. Earlier API versions continue to return the oldest resources first. Teams can access recent activity immediately instead of paginating to the end of a collection. Integrations on `2026-03-30` that assume the first result is the oldest should update their ordering logic. For more information, visit the [Pagination](/reference/pagination) documentation. ### Payability for Stale Liabilities Method now removes the `payment` product from liabilities with bureau data that stopped being reported or has not updated in years. These accounts are often no longer in a payable state, so this change helps prevent avoidable payment failures. The Account remains discoverable and may continue to support other available products. Check the Account's `products` array before presenting it as a payment destination. For more information, visit the [Connect account discovery](/guides/connect/overview) guide. ### Expanded Check Payment Coverage Method can now support check payments to American Express, Apple Card, and Barclays without requiring the end user to complete an additional account verification step. This creates a payment path for supported accounts when electronic delivery is unavailable, and minimizes drop-off caused by requiring users to manually enter their account number. Teams can complete more debt payments without sending users through an additional verification flow or excluding these accounts. This capability is gated and uses paper checks, not electronic delivery. Contact your Method CSM to enable it. For more information, visit the [Payments](/guides/payments/overview) documentation. ### Estimated Reversal Completion Dates Eligible Reversals now include an `estimated_completion_date`, giving teams a clear date to use when setting expectations for returned funds. The field uses `YYYY-MM-DD` format and returns `null` when an estimate is unavailable, including for reversal types outside the supported path. Teams can use the estimate in payment tracking, support messaging, and reconciliation workflows instead of applying a fixed timeline to every Reversal. For more information, visit the [Payments](/reference/payments/overview) documentation. ### Partial Reversal Visibility Method is adding visibility for partial reversals. When only part of a payment is returned, teams will be able to identify the exact returned amount and track it separately from the original Payment. This removes manual reconciliation and reduces the risk of refunding the full payment when only part was returned. Additionally, Method is publishing Reversal API documentation. Teams will be able to list all Reversals associated with a Payment or retrieve a specific Reversal to track its amount and current status. This provides a documented workflow for tracking returned funds across full and partial reversals. For more information, visit the [Payments](/reference/payments/overview) documentation. ### Payment Implementation Guides New implementation guides make it easier to compare, select, and set up your payment flows, from the back-end infrastructure to the front-end UI: * [Flow of Funds Setup](/guides/payments/flow-of-funds) compares FBO funding with per-payment funding, walks through each step of building the flow and funding accounts, and details how to handle reconciliation and returns. * [Direct Pay UI Best Practices](/guides/payments/ui-best-practices) provides a reference checklist for designing a consumer Direct Pay experience to maximize conversion and customer satisfaction. Previously, teams had to piece together funding, reconciliation, and user-interface requirements across multiple references. The new guides provide one path from payment-model selection through implementation and payment tracking. ### Development Environment Teams can now test error handling, response mapping, and user experiences against a wider range of credit profiles before using live data. The development environment now includes additional raw credit report samples and Connect error scenarios, including report failures, thin or unavailable bureau data, derogatory and fraud-alert files, and successful reports with different inquiry, collection, and tradeline combinations. These scenarios are available in Development only. For more information, visit the [Development Environment](/reference/environments) documentation. ## Fixes ### Wallet Intelligence Attribute Consistency Wallet Intelligence now returns `spend_concentration_*` attributes as percentages, consistent with `utilization`, and keeps curated-bundle attributes in their requested bundle. Teams can compare wallet ratios directly without converting units or filtering unexpected fields. Existing values update the next time Method computes them. For more information, visit the [Account Attributes](/reference/accounts/attributes/overview) documentation. ### Payment Status and Settlement Dates Payment states and settlement dates now better match the underlying movement of funds. Batched ACH payments receive the correct source status, standard ACH uses its intended settlement schedule, and instant reversals reflect the day funds moved. This reduces reconciliation gaps and stale payment states. For more information, visit the [Payments](/reference/payments/overview) documentation. ### Automated Check Reversals Method is introducing an automated reversal workflow for returned paper checks. When Method receives an eligible returned check, it matches the check to the original Payment, applies the required clearing hold, creates a Reversal, and moves the Payment into `reversal_processing`. Teams will receive the existing `payment.update`, `payment_reversal.create`, and `payment_reversal.update` webhooks as the Payment and Reversal move through their lifecycles. This removes manual follow-up and provides a consistent API and webhook trail for returned checks. For more information, visit the [Payments](/reference/payments/overview) documentation. ### Connect and Subscription Stability Configured account products now run for subscription-created Connects, and changing on-demand product access no longer cancels active subscriptions. Teams receive consistent product results and uninterrupted subscription updates without integration changes. For more information, visit the [Connect](/reference/entities/connect/overview) and [Subscriptions](/guides/connect/subscriptions) documentation. ### Dashboard Payment Search Canceled payments now remain searchable in the Method Dashboard, so operations and support teams retain the full payment history for investigations and reconciliation. ### Opal Account Selection Opal now keeps ineligible accounts visible but prevents users from selecting them in multi-select Card Connect flows, reducing avoidable errors and retries. For more information, visit the [Opal Card Connect](/opal/card_connect/overview) documentation.