New anti-fraud service
Adds an anti-fraud service, enabling merchants to determine risky transactions and prevent chargebacks.
This endpoint requires the anti-fraud-services.write
scope.
Authorizations
Bearer authentication header of the form Bearer <token>
, where <token>
is your auth token.
Body
A request to create an anti-fraud service.
The name of the Anti-Fraud service provider. During update request, this value is used for validation only but the underlying service can not be changed for an existing service.
cybersource-anti-fraud
, forter-anti-fraud
, sift-anti-fraud
A unique name for this anti-fraud service which is used in the Gr4vy admin panel to give a anti-fraud Service a human readable name.
1 - 200
A list of fields, each containing a key-value pair for each field defined
by the definition for this anti-fraud service e.g. for Sift
api_key
must be sent within this field when creating the service.
For updates, only the fields sent here will be updated, existing ones will not be affected if not present.
Defines if this service is currently active or not. There can only be one active service at any time. When updating a service to active, the current active service will be deactivated.
Defines if this service needs to handle the review status from anti-fraud responses with a proper review workflow. If not, the review status will be treated as any other one.
Response
The type of this resource. Is always anti-fraud-service
.
anti-fraud-service
The unique Gr4vy ID for this anti-fraud service.
The unique ID for a merchant account.
The name of the Anti-Fraud service provider. During update request, this value is used for validation only but the underlying service can not be changed for an existing service.
cybersource-anti-fraud
, forter-anti-fraud
, sift-anti-fraud
A unique name for this anti-fraud service which is used in the Gr4vy admin panel to give a anti-fraud service a human readable name.
1 - 200
Defines if this service is currently active or not.
Defines if this service needs to handle the review status with a proper review workflow. If not, the review status will be treated as any other one.
A list of fields, each containing a key-value pair for anti-fraud service decision mapping e.g. for Sift approve_decision
will be in the response.
The date and time when this anti-fraud service was created in our system.
The date and time when this anti-fraud service was last updated in our system.
Was this page helpful?