This page lists the mandatory operational fields that must be sent on Create Evaluation (POST /v1/antifraud/evaluations) when the merchant is covered by chargeback guarantee, plus the chargeback notification that must be sent after a dispute is reported.
These requirements complement the base OpenAPI contract. Incomplete or empty objects (for example address: {}) may cause validation errors or exclude the transaction from guarantee eligibility.
Public HTTPS endpoint for async evaluation status updates.
2. buyer (required)
Field
Required
Notes
email
Yes
Buyer email.
full_nameor (first_name + last_name)
Yes
Provide full name or first and last name.
phone
Yes
See phone fields below.
document
Yes
See document fields below.
address
Yes
Full address — see address fields below. Do not send an empty object.
buyer.phone
Field
Required
Notes
area_code
Yes
Area / DDD code.
type
Yes
Phone type (for example Mobile).
number
Yes
Phone number.
country_code
Recommended
For example +55.
buyer.document
Field
Required
Notes
type
Yes
Document type (for example CPF, DNI).
number
Yes
Document number.
nationality
Recommended
Two-letter ISO 3166 country code when available.
buyer.address (full address)
Field
Required
Notes
street
Yes
Street name.
number
Yes
Street number.
neighborhood
Yes
Neighborhood / district.
city
Yes
City name or code.
state
Yes
State name or code.
country_code
Yes
Two-letter ISO 3166 country code.
zip_code
Yes
Postal / ZIP code.
complement
When available
Apartment, floor, landmark, etc.
3. device (required)
Field
Required
Notes
ip_address
Yes
Buyer device IP (IPv4 or IPv6).
session_id
Yes
Session / fingerprint session identifier.
For web checkouts, also integrate device fingerprint per JavaScript Integration and send the token in device as defined in the current OpenAPI.
4. store (required)
Field
Required
Notes
code
Yes
Store / merchant code configured with Koin.
reference_id
Yes
Merchant order identifier. Must stay stable between pre-evaluation and evaluation when both are used.
category
Recommended
MCC (merchant category code), when available.
5. items[] (required)
Each element must include the shared Item base fields:
Field
Required
Notes
type
Yes
Item discriminator (for example Generic, Flight, Bus).
id
Yes
Line / SKU identifier in your catalog.
name
Yes
Product or service name.
quantity
Yes
Quantity sold.
category.id
Yes
Category identifier.
category.name
Yes
Category name.
price.currency_code
Yes
ISO 4217 currency code.
price.value
Yes
Unit / line price value.
Additional fields may be required depending on items[].type. See the item types index.
6. payments[] — CreditCard (required for card flows)
Field
Required
Notes
type
Yes
CreditCard.
amount.currency_code
Yes
ISO 4217 currency code.
amount.value
Yes
Payment amount.
details.bin
Yes
Card BIN (first digits).
details.expiration_month
Yes
Card expiration month.
details.expiration_year
Yes
Card expiration year.
payer
Yes
Payer identity — see below.
Prefer tokenized card data (secure_token) when available. Do not send full PAN or CVV in clear text unless the published contract for your API version explicitly requires it.
payments[].payer
Field
Required
Notes
full_nameor (first_name + last_name)
Yes
Payer name.
document.type
Yes
Document type.
document.number
Yes
Document number.
document.nationality
Yes
Two-letter ISO 3166 country code.
7. transaction (required)
Field
Required
Notes
reference_id
Yes
Unique business transaction identifier (max length / pattern per OpenAPI). Align with store.reference_id as defined by your integration.
8. shipping (required when delivery applies)
Field
Required
Notes
address
Yes
Full shipping address — same completeness rule as buyer.address.
shipping.address
Field
Required
Notes
street
Yes
Street name.
number
Yes
Street number.
neighborhood
Yes
Neighborhood / district.
city
Yes
City name or code.
state
Yes
State name or code.
country_code
Yes
Two-letter ISO 3166 country code.
zip_code
Yes
Postal / ZIP code.
complement
When available
Additional address details.
9. Example — Create Evaluation (minimum for chargeback guarantee)
Illustrative payload. Replace values with real data and validate against the current OpenAPI.
10. Chargeback notification (mandatory after dispute)
When a chargeback (or equivalent dispute) is reported for an already evaluated transaction, the merchant must notify antifraud using Send Notifications.
Send the chargeback notification whenever the acquirer, issuer, or merchant operations report a chargeback on an evaluated transaction, within the agreed operational window.
Implement retry with backoff for transient failures (5xx, timeout) without duplicating business side effects.
Other notification types (RFI, STATUS, INFO) remain available on the same endpoint; for chargeback guarantee coverage, CHARGEBACK is the mandatory dispute signal.