## TL;DR

dLocal validates that the payment method is offered in the country you send: a wrong or unsupported country code, or a method not available in that market, rejects the direct charge. Check dLocal's coverage for the method, send the two-letter ISO country code in the expected case, and retry. If the method truly is not offered there, choose an available local method instead of forcing the code.

```text
dlocal invalid country code for the payment method on a direct charge
```

## Use this when

- dLocal direct charge fails with invalid country code for the payment method
- You are adding a new market to an existing dLocal integration
- A method works in one country but not another

## Not for this skill when

- The card is declined after the method is accepted
- The currency is unsupported (different validation)
- You are debugging payouts rather than charges

## Steps

1. Confirm the country code you sent: two-letter ISO format, matching the customer's market.
   Expected: The code is a valid ISO country code.
2. Check dLocal's documentation or your account manager's coverage sheet for whether the payment method is offered in that country.
   Expected: You know if the method/country pair is supported.
3. Correct the country code on the charge request.
   Expected: The request carries the right country.
4. If the pair is unsupported, switch to a local payment method dLocal offers in that country.
   Expected: The charge uses an available method.
5. Re-run the direct charge.
   Expected: dLocal accepts the charge.

## Tool compatibility

dLocal payments API direct charge; country/method coverage is account- and region-dependent.

## Variant phrasings

### dlocal country code invalid payment method

Word-order variant of the same error.

### dlocal payment method not available country

The coverage interpretation of the failure.

### dlocal direct charge country mismatch

The request-data angle.

## Why it happens

dLocal aggregates hundreds of local payment methods across emerging markets, and each method exists only in specific countries. The API validates the method/country pair up front so merchants do not send charges into rails that cannot settle them. A typo in the country code, or assuming a method's availability transfers across borders, trips this validation. The fix is data correction or method substitution, never a retry of the same pair.

## Edge cases / pitfalls

- Country codes are case-sensitive in some integrations: match the case dLocal expects.
- Coverage changes over time: re-check the sheet before launching in a new market.
- The customer's billing country and the processing country can differ; send the one dLocal validates against.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9DyYOVLB0cYf2cMR7X7QXQ