This reference is key for your comprehensive understanding of LOGPAY Token Service.
LOGPAY's APIs make use of RESTful conventions when possible and where it makes sense. All calls use the standard HTTP verbs to express access semantics, like GET, POST, PATCH, and DELETE. Other related conventions for our API can be found in the section below.
id property.snake_case.null value instead.API keys are supported to authenticate requests.
The keys are passed in via the HTTP header x-api-key.
curl --header 'X-API-Key: <SECRET>' \
--request POST 'https://test.token.logpay.de/...'The keys must be handled with care and kept secure. Never hardcode the API keys in your source code, but keep them solely on your backend systems.
Endpoints that return lists of objects support cursor-based pagination requests. By default, the API returns up to 50 objects per API call. If the number of objects in a response from a support endpoint exceeds the default, then an integration can use pagination to request a specific set of the results and/or to limit the number of returned objects.
If an endpoint supports pagination, the response body follows this structure:
{
"current_page": 1,
"page_size": 50,
"total_items": 200,
"total_pages": 4,
"data": [...]
}The single pages can be requested with query parameters:
| Parameter | Type | Description |
|---|---|---|
limit | integer | The maximum amount of objects to be returned on a page. |
page | integer | The requested number of the page to return. |
The API uses the standard errors to indicate the client errors on the service level.
The response payload for processing errors follows a standard format.
{
"status": "the HTTP status code",
"classifier": "the classifer of the error",
"message": "interesting for humans..."
}The processing errors refer to the primary functions of the LOGPAY Token Service and not necessarily to the related business logic. For example, a failed authorization due to insufficient funds will result in a 200 response, as the payment layer could successfully process the request (even though the business result is negative).
https://test.token.logpay.de/
LOGPAY Tokens are powerful instrument to manage card holder data in a PCI/DSS compliant way.
Achieve PCI / DSS compliance in almost no time using our certified managed compliance service.
Transparently use the cardholder data across all connected processors to implement a non lock-in acquiring setup.
For every card which is tokenized, network-tokens can be automatically provisioned. This allows for more secure transactions, better conversion, and ultimately lower processing cost.
All cards stored with LOGPAY can be managed via the endpoints in this section.
The CVC2 security code is only kept in an ephemeral cache for a few minutes. The API allows to manage this resource with these endpoints:
LOGPAY supports Network Tokens with major card schemes.
The lifecycle of network tokens is automatically managed. When activated a network token is automatically provisioned and maintained through its life-cycle.
The use of Network Tokens requires prior activation by your account manager.
https://test.token.logpay.de/tokens/{id}/payment-data
curl -i -X GET \
'https://test.token.logpay.de/tokens/{id}/payment-data?limit=1&page=1&sort=string' \
-H 'X-API-Key: YOUR_API_KEY_HERE'{ "data": [ { … } ], "pagination": { "current_page": 1, "page_size": 1, "total_items": 1, "total_pages": 1 } }
https://test.token.logpay.de/tokens/{id}/provisions
curl -i -X POST \
'https://test.token.logpay.de/tokens/{id}/provisions' \
-H 'X-API-Key: YOUR_API_KEY_HERE'Success response
The url linking to the card art endpoint
The date-time the payment-method was created (following ISO 8601)
The date-time when the token will expire. Applicable only for ephemeral tokens.
The time the LOGPAY Token was invalidated, because the underlying payment instrument was invalidated by the scheme.
The issuer idenfication number (IIN) - also known as BIN
The full lenght of the card number, but masked to conform to PCI/DSS requirments
A two letter country code. ISO 3166-1 alpha-2
The status of the associated network token.
| Status | Description |
|---|---|
active | The network token is active and can be used. |
inactive | The network token is inactive, which prevents using it. The reason can be for example suspended network token. |
pending | A network token is currently being provisioned. As soon as this is available, the status is changed to active. |
failed | A network token failed to be provisioned. |
deleted | The network token is deleted and cannot be used again. It is also not possible to activate the network token again. |
not_available | A network token can not be provisioned with the current configuration. |
The scheme in which the card was issued
The type of ID&V submitted during the creation of the LOGPAY token..
This attribute holds the original business key under which the cardholder data was stored on the system from which it was imported to Logpay.
It can be used for reconciliation or reference purposes.
{ "id": "5d6b2c9a-9b0b-4b0c-8c7d-9e9d5d7e9d5d", "cardholder_name": "John Doe", "card_art_url": "https://test.token.logpay.de/tokens/card-art/374c911a-8125-40eb-acb8-a26efd25f02b", "created_at": "2023-10-01T00:00:00Z", "expiry_month": 4, "expiry_year": 2033, "expires_at": "2023-10-07T00:00:00Z", "issuer_identification_number": "424242", "masked_account_number": "424242******4242", "network_token_status": "active", "scheme": "VISA" }