New payment service
Adds a new payment service by providing a custom name and a value for each of the required fields.
This endpoint requires the payment-services.write scope.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Body
Request body for activating a payment service.
The ID of the payment service to use.
1 - 50A custom name for the payment service. This will be shown in the Admin UI.
1 - 50A list of fields, each containing a key-value pair for each field defined by the definition for this payment service e.g. for stripe-card secret_key is required and so must be sent within this field.
A list of countries that this payment service needs to support in ISO two-letter code format.
A list of currencies that this payment service needs to support in ISO 4217 three-letter code format.
The reporting_fields field should contain a list of key-value pairs. Each key-value pair represents a reporting field defined by the payment service. For example, when enabling settlement reporting for nuvei-card, the ssh_username field is required and must be included in reporting_fields.
Defines if 3-D Secure is enabled for the service. This feature
can only be enabled if the payment service definition supports
the three_d_secure_hosted feature.
This does not affect pass through 3-D Secure data.
Configuration for each supported card scheme.
Defines if this service is currently active or not.
Defines if the service works as an open-loop service. This feature can only be enabled if the PSP is set up to accept previous scheme transaction IDs.
If this value is not provided or is set to null, it will be set
to the value of open_loop in the payment service definition.
If open_loop_toggle is false in the payment service definition,
open_loop should either not be provided or set to null, or it
will fail with a validation error.
Defines if tokenization is enabled for the service. This feature
can only be enabled if the payment service is NOT set as open_loop
and the PSP is set up to tokenize.
Defines if network tokens are enabled for the service. This feature
can only be enabled if the payment service is set as open_loop and
the PSP is set up to accept network tokens.
If this value is not provided or is set to null, it will be set
to the value of network_tokens_default in the payment service
definition.
If network_tokens_toggle is false in the payment service definition,
network_tokens_enabled should either not be provided or set to null,
or it will fail with a validation error.
Defines if settlement reporting is enabled for the service.
This feature can only be enabled if the payment service
definition supports the settlement_reporting feature.
Response
An active, configured payment service.
The type of this resource.
payment-service The ID of this payment service.
1 - 200A list of countries for which this service is enabled, in ISO two-letter code format.
A list of currencies for which this service is enabled, in ISO 4217 three-letter code format.
Defines if this service is currently active or not.
The date and time when this service was created.
The custom name set for this service.
1 - 200A list of fields, each containing a key-value pair for each field
configured for this payment service. Fields marked as secret
(see Payment Service Definition) are not returned.
A list of fields, each containing a key-value pair for each field
configured for reporting for this payment service. Fields marked as
secret (see Payment Service Definition) are not returned.
The unique ID for a merchant account.
An object containing a key for each supported card scheme (Amex, Discover, Mastercard and Visa), and for each key an object with the merchant profile for this service and the corresponding scheme.
The payment method that this service handles.
afterpay, alipay, alipayhk, applepay, bacs, bancontact, banked, becs, bitpay, boleto, boost, card, cashapp, chaseorbital, checkout-session, clearpay, click-to-pay, dana, dcb, dlocal, ebanx, efecty, eps, everydaypay, gcash, gift-card, giropay, givingblock, gocardless, googlepay, googlepay_pan_only, gopay, grabpay, id, ideal, kakaopay, kcp, klarna, laybuy, linepay, linkaja, maybankqrpay, mercadopago, multibanco, multipago, netbanking, network-token, oney_3x, oney_4x, oney_6x, oney_10x, oney_12x, ovo, oxxo, payid, paymaya, paypal, paypalpaylater, payto, venmo, pix, pse, rabbitlinepay, razorpay, scalapay, sepa, shopeepay, singteldash, smartpay, sofort, spei, stripedd, thaiqr, touchngo, truemoney, trustly, trustlyeurope, upi, vipps, waave, webpay, wechat, zippay Defines if network tokens are enabled for the service. This feature
can only be enabled if the payment service is set as open_loop and
the PSP is set up to accept network tokens.
Defines if the service works as an open-loop service. This feature can only be enabled if the PSP is set up to accept previous scheme transaction IDs.
Defines if tokenization is enabled for the service. This feature
can only be enabled if the payment service is NOT set as open_loop
and the PSP is set up to tokenize.
The ID of the payment service definition used to create this service.
1 - 50Defines if settlement reporting is enabled for the service.
This feature can only be enabled if the payment service
definition supports the settlement_reporting feature.
The current status of this service. This will start off as pending, move to created, and might eventually move to an error status if and when the credentials are no longer valid.
pending, created, failed Defines if 3-D Secure is enabled for the service. This feature
can only be enabled if the payment service definition supports
the three_d_secure_hosted feature.
This does not affect pass through 3-D Secure data.
The date and time when this service was last updated.
The URL that needs to be configured with this payment service as the receiving endpoint for webhooks from the service to Gr4vy. Currently, Gr4vy does not yet automatically register webhooks on setup, and therefore webhooks need to be registered manually by the merchant.
Was this page helpful?