Payer Data Quality
Quick Reference
Keep sending the charge you send today. Before it reaches the acquirer, we check every payer field, fix what can be fixed with certainty, and tell you exactly what happened.
Why it matters
Payer data gets damaged between the checkout and the acquirer: a postal code loses its leading zero, the house number stays inside the street, the state arrives written in full. Each inconsistency makes a genuine buyer look less trustworthy.
It has a measurable cost. Across more than 250,000 approved sales in our history, sales whose address fields disagreed were disputed about twice as often as sales whose fields agreed (1.73% against 0.82%).
What changes on a charge
| Field | You send | The acquirer receives |
|---|---|---|
| Street | 200 Main St | 200 Main St |
| House number | empty | 200 |
| City | Boston | Boston |
| State | Massachusetts | MA |
| Postal code | 2108 | 02108 |
What you gain
| No integration work | Enabled on your account. Your request stays the same. |
| Consistent data at every acquirer | Each field goes in the format that acquirer expects, on every route. |
| Addresses you can rely on | When a US postal code is unusable, the right one comes from official postal data. In our test on addresses with a known postal code, 190 of 191 answers were correct. |
| A stronger position in disputes | The buyer's record stays the same from one purchase to the next, which is what you need when contesting a chargeback. |
| Full visibility | Every charge tells you, field by field, what was checked and what was changed. |
| No cost to checkout speed | The checks take microseconds. The only outside confirmation happens the first time a buyer has an unusable postal code, is limited to about one second, and never stops a sale. |
Approval is always the issuer's decision. What this feature removes are the avoidable reasons for doubt.
How it works
- Standardise. Country, state, phone and house number go in the expected format.
- Check. Postal code, city and state are compared with each other against public references.
- Correct, only with certainty. A field changes only when other data from the same buyer confirms the right value.
- Record. Your original request is kept unchanged, and every change is logged with its rule and source.
See what happened
The charge response and the webhook carry a data_quality object. It holds statuses, never payer values.
"data_quality": {
"version": "1",
"mode": "standard",
"fields": {
"payer_address.postal_code": { "status": "certified", "rule": "US-CERT-01", "source": "postal_authority" },
"payer_address.address_number": { "status": "normalized", "rule": "ADDR-NUM-01", "source": "street" },
"payer_cell_phone": { "status": "valid" }
},
"flags": []
}
| Status | Meaning |
|---|---|
valid | Passed the checks |
normalized | Same information, in the standard format |
corrected | Corrected because other data from the buyer confirms the right value |
certified | Confirmed against official postal data |
unverified | Present, but nothing confirms it; reason explains when known |
missing | Not sent |
flags are informational and new ones may be added, so do not build logic that fails on an unknown flag.
You stay in control
Optional, per charge:
"data_quality": { "mode": "standard" }
| Mode | What happens |
|---|---|
standard | Checks and corrects. Default. |
validate_only | Only reports. The data goes as you sent it. |
off | The feature is skipped for this charge. |
What it never does
- It never invents names, documents, addresses or device data.
- It never rewrites the buyer's name or city.
- It never alters the request you sent.
If an acquirer requires a field that does not exist, such as a house number, the value that acquirer accepts is used and the field is reported as unverified.
Get the most out of it
The closer the data is to the buyer, the better the result: send the postal code and state as typed at checkout, the buyer's public IP, and browser data read from the buyer's device.
Turn it on
Talk to your account manager. No code change is needed.