August Updates

New Features

Wallet Intelligence

Method now offers Wallet Intelligence: behavioral attributes computed across the credit cards in a customer’s connected wallet, so segmentation, eligibility, and offer-targeting logic can run directly on the data your team receives from Method. Retrieve wallet-level attributes with a single request: POST /entities/{ent_id}/attributes. The endpoint is asynchronous; receive completed results through the attribute webhook or the retrieve endpoint. Previously, merchants and marketplaces had to collect card data and model wallet behavior themselves to target offers or segment customers. With Wallet Intelligence, those signals arrive computed and ready to use: identify customers most likely to benefit from an offer, deliver issuer and partner offers only to eligible customers, and understand wallet trends to inform product decisions. Contact your Method CSM to enable Wallet Intelligence for your team. Utilization and activity trends: per-card signals for how usage is changing

Attribute	Type	Description
`utilization_velocity_4_week`	`enum`	Utilization trend over 4 weeks. See the Entity Attributes reference for current enum values.
`utilization_velocity_8_week`	`enum`	The same trend over the last 8 weeks.
`utilization_velocity_12_week`	`enum`	The same trend over the last 12 weeks.
`weeks_since_last_activity`	`enum`	Time since the balance last changed, in four-week buckets from `under_4_wks` to `24_plus_wks`.
`recent_balance_spike_flag`	`boolean`	`true` when the balance is at least 1.5x a reading from 5 to 21 days back and the growth is at least 5% of the credit limit.

Wallet composition: how each card fits into the customer’s full wallet

Attribute	Type	Description
`spend_concentration_4_week`	`number`	The card’s share of the wallet’s total balance over 4 weeks, from 0 to 1.
`spend_concentration_8_week`	`number`	The same share over 8 weeks.
`spend_concentration_12_week`	`number`	The same share over 12 weeks.
`current_wallet_rank`	`integer`	The card’s concentration rank among the wallet’s cards; 1 is the highest.
`healthy_cards_count`	`integer`	Entity-level. Cards with a transactor usage pattern.
`dormant_cards_count`	`integer`	Entity-level. Cards with a dormant usage pattern.
`delinquent_cards_count`	`integer`	Entity-level. Cards with a delinquent signal.
`net_active_cards_count`	`integer`	Entity-level. Open, non-dormant cards.

Card brand reference: what kind of card each one is

Attribute	Type	Description
`brand_category`	`enum`	The card’s product category, such as `travel`, `dining`, `groceries`, `cash_back_flat`, `cash_back_varied`, `retail`, or `credit_builder`.
`brand_tier`	`enum`	The card’s tier: `lux`, `premium`, `plus`, `basic`, `credit_builder`, or `retail`.

For more information, visit the Wallet Intelligence guide and the Entity Attributes reference.

OAuth 2.0 Client Credentials

Method now supports OAuth 2.0 client credentials as an alternative to API keys, for teams whose security programs require scoped, short-lived, rotatable credentials. Instead of a single long-lived key with full access, you exchange a client_id and client_secret for a short-lived access token and call the API with that token.

Create and manage OAuth clients in the Method Dashboard. Each environment has its own clients.
Exchange credentials at POST /oauth/token for an access token that expires after one hour.
Scopes follow <resource>:<action> (for example, entities:read, accounts:read, payments:write), so each client is constrained to the subset of the API it needs.
A client_secret is shown exactly once at issuance, and Method never stores a readable copy. Mint a new secret before disabling the old one to rotate without downtime.

{
  "access_token": "oat_7Hk94r83482csdcK2mQx9vTz",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "entities:read accounts:read"
}

Each service or vendor gets its own client with only the access it needs, tokens expire on their own, and if a credential leaks you disable that one client while every other integration keeps running. API keys continue to work unchanged, and no migration is required. For more information, visit the Authentication documentation.

Mutual TLS (mTLS)

Together with OAuth client credentials, mutual TLS gives larger enterprise customers with complex security requirements more flexibility in how they authenticate to Method. Teams whose security programs require certificate-based authentication can now present a client certificate on every request, which Method verifies in addition to API credentials. Once a team is provisioned, every request must present:

A client certificate registered to the team.
A valid Method API key or OAuth access token.

Multiple certificates can be registered at once, so a new certificate can be put in place before the old one expires. mTLS is optional and opt-in. It is provisioned per team and per environment, the API hostnames do not change, and teams that are not provisioned are unaffected. Contact your Method CSM to have your team provisioned. For more information, visit the Mutual TLS documentation and the mTLS Errors reference.

Improvements

Discover Card Brand Support

The Card Brands endpoint now returns brand data for Discover cards. Discover cards now return the same card art and product detail as every other supported network, through the same request and response structure, so your users see their full wallet regardless of which network issued their cards. No integration changes are required, and the card data pipeline gained new monitoring so any future coverage gap surfaces quickly. For more information, visit the Card Brands documentation.

Card Network on Accounts

Liability accounts now surface the card network directly on the account object. For credit card liabilities, account.liability.network returns the network (for example, visa, mastercard, amex, discover); it returns null for other liability types or when Method cannot determine the network.

{
  "liability": {
    "type": "credit_card",
    "network": "discover"
  }
}

You can render the right network badge, segment a portfolio by network, or apply network-specific logic directly from the account, without a separate Card Brands request and without handling card numbers. The field is populated automatically for all teams on all API versions. For more information, visit the Accounts documentation.

Masked Card Number Format

For teams configured to receive masked Payment Instrument card data, the masked number format now shows the first six digits (the BIN) and the last four digits in the clear. Each digit in between is masked one-for-one, so the masked value keeps the length of the number on file.

{
  "card": {
    "number": "555555xxxxxx0332",
    "exp_month": "xx",
    "exp_year": "xxxx",
    "cvv": "xxx",
    "billing_zip_code": "xxxxx"
  }
}

The visible digits are enough to enroll a card with third-party providers, such as loyalty and rewards programs, and to tell cards apart in your UI, while your systems remain PCI compliant. Expiration dates, CVVs, and billing ZIP codes remain fully masked, and card numbers shorter than 13 digits remain fully masked.

If your team already receives masked card data, this format replaces the fully masked format. Update any parsing or display logic that expects the old format.

For more information, visit the Payment Instruments documentation.

Webhook Delivery IP Addresses

Method webhook deliveries can now originate from three additional static IP addresses shared across all environments: 104.28.1.162, 104.28.0.19, and 104.28.0.18. The same three addresses apply in every environment, simplifying firewall rules and security reviews. If your team restricts inbound webhook traffic by IP, add all three addresses to your allowlist alongside the existing environment-specific addresses. For more information, visit the IP Whitelisting documentation.

ACH Reference IDs on Inbound Payments

For inbound ACH transfers received through an inbound_achwire_payment Payment Instrument, Method now records the receiver identification number from the NACHA Entry Detail Record on the Payment object in metadata.ach_reference_id when the originator provides one. If Method returns the funds to the original source account, the outbound ACH credit automatically carries the same value as the confirmation ID in its Entry Detail Record (record type 6).

{
  "metadata": {
    "ach_reference_id": "REF-2026-081801"
  }
}

Operations teams can match a Method payment or reversal to the originating instruction in their treasury system automatically, instead of reconciling returns by amount and date. Payment simulations in the development environment accept ach_reference_id, so the flow can be tested end to end before any live funds move. For more information, visit the Payments documentation.

Dashboard

The Method Dashboard now includes:

OAuth client management: Manage scopes, permissions and secrets.
Security settings: Managing the IP allowlist for the API is now self-service.
Payment detail: ACH destination details on the payment detail page.
Faster navigation: Views and merchant logos preload, and a bug that prevented API keys from being deleted has been fixed.

Together these give admins self-serve control over credentials and network security.

Connect and Card Brands Performance

For supported commerce use cases, Connect latency on card data flows has been cut roughly in half and now completes in under a second, so customers can load their wallets and connected cards without slowing down checkout or linking. Availability is use-case dependent; contact your Method CSM if you are interested. Card Brands request throughput has also increased, and brand data can now be refreshed from a card’s existing network token without requiring a new Connect. These changes require no integration updates.

Development Environment

The development environment now enforces the one-time payment maximum amount limit, matching production behavior. Limit errors now surface while you are still testing, instead of appearing for the first time in production. For more information, visit the Development Environment documentation.

Changelog

API Versions

New Features

Wallet Intelligence

OAuth 2.0 Client Credentials

Mutual TLS (mTLS)

Improvements

Discover Card Brand Support

Card Network on Accounts

Masked Card Number Format

Webhook Delivery IP Addresses

ACH Reference IDs on Inbound Payments

Dashboard

Connect and Card Brands Performance

Development Environment

​New Features

​Wallet Intelligence

​OAuth 2.0 Client Credentials

​Mutual TLS (mTLS)

​Improvements

​Discover Card Brand Support

​Card Network on Accounts

​Masked Card Number Format

​Webhook Delivery IP Addresses

​ACH Reference IDs on Inbound Payments

​Dashboard

​Connect and Card Brands Performance

​Development Environment

New Features

Wallet Intelligence

OAuth 2.0 Client Credentials

Mutual TLS (mTLS)

Improvements

Discover Card Brand Support

Card Network on Accounts

Masked Card Number Format

Webhook Delivery IP Addresses

ACH Reference IDs on Inbound Payments

Dashboard

Connect and Card Brands Performance

Development Environment