Troubleshooting “no_billing_information” After Updating the Recurly Wallet

Symptoms

• Renewals (or manual charges) decline with no_billing_information.
• A card (or other payment method) appears in the account’s Wallet, but charges still fail as if nothing is on file.
• When updating billing details programmatically, your request fails with an HTTP 422 error similar to:
  • Cannot assign verification value to non credit card billing info

Why this happens (most common causes)

Cause 1: No “Primary” payment method is set in the Wallet

With Wallet enabled, an account can store multiple payment methods, but Recurly still needs a primary payment method to charge by default. If the primary is missing, invalid, or deleted, renewals can fail with no_billing_information.

Cause 2: Your integration is updating billing info using a legacy pattern that doesn’t match the payment method type

A common pattern is sending a verification_value (CVV) during an update when the underlying billing object is not a credit card (for example: PayPal / wallet-based methods / certain gateway token flows). In those cases, Recurly may reject the update with HTTP 422 (e.g., Cannot assign verification value to non credit card billing info).

Cause 3: A “successful-looking” update didn’t actually attach a billable method

For example, you may be saving a token in your system, but not creating/updating a Wallet payment method successfully in Recurly, leaving the account without a billable primary.

Quick fix (get renewals unstuck)

1. Confirm the account has at least one valid payment method in the Wallet.
2. Confirm one method is marked as Primary.
3. If a method looks present but billing still fails:
   • Remove the invalid/stale method (or clear the billing info), then re-add the payment method and set it as primary.

Step-by-step in the Recurly UI

1. Open the customer Account in the Recurly Admin Console.
2. Navigate to the customer’s Wallet / Payment Methods section.
3. Verify there is at least one payment method and that it is Primary.
4. If there is no primary method:
   • Set the intended payment method as Primary, then retry the renewal/charge.
5. If the Wallet shows a method but renewals still fail:
   • Remove the method that appears stale/invalid (especially after failed API updates).
   • Add a fresh payment method and set it as Primary.
   • Retry billing.

Tip: If you’re unsure which method Recurly is trying to use, check the invoice/transaction details and confirm the payment method type matches your expectation.

Step-by-step via API (recommended approach)

1) Confirm what payment method(s) exist and which is primary

Retrieve the account’s payment methods and verify:

• There is at least one payment method in a billable state.
• Exactly one is marked as primary (or the correct one is primary).

(Exact endpoint names can vary by API version and client library. If you share your API version and the call you’re using, Support can map this to your exact integration quickly.)

2) When updating a card, do not send CVV unless the target object is a credit card

• If you are updating/creating a credit card, CVV may be supported depending on your flow (e.g., tokenization via Recurly.js / supported gateway token flows).
• If the method is not a credit card (PayPal, wallet-based methods, certain token flows), omit verification_value.

3) Create/attach the payment method to the Wallet and set it as primary

Pseudocode example (illustrative):

{
  "payment_method": {
    "token_id": "token-from-your-tokenization-flow",
    "primary": true
  }
}

4) Retry the renewal/charge

Once the account has a valid primary payment method, retried invoices/renewals should no longer fail with no_billing_information.

Prevention checklist

• Always set a primary payment method when adding a new method to the Wallet (or ensure your UI prompts the customer to choose).
• Validate method type before sending CVV:
  • Send CVV only for credit-card objects/flows where it is supported.
  • Do not send verification_value for non-card payment methods.
• If you support multiple payment methods per customer, ensure your integration logic is Wallet-aware (don’t assume “one billing info record”).
• Log and alert on:
  • HTTP 422 responses during payment method updates
  • Renewal declines with no_billing_information

FAQ

Why does the Wallet show a card, but billing says no_billing_information?

Most commonly, the “visible” method is not set as Primary, is not in a billable state, or a failed update left the account without a usable primary payment method.

Is this specific to a gateway?

The symptom can occur with multiple gateways because it’s typically caused by how the payment method is being updated/attached (and whether the payload matches the method type), not the gateway alone.

What should I provide to Support if I still can’t resolve it?

• Site subdomain
• Account code(s) impacted
• Invoice number(s) showing no_billing_information
• Your API version + the exact endpoint(s) you use to create/update payment methods
• Full request/response for the failing update (redacted)
• Whether Wallet is enabled and whether multiple payment methods are expected on the account