Quality of life improvements II
We improved several parts of our API, especially for the organization
& transaction
platform entities.
Update organization data
It is now possible to update organization details via š PATCH /organization/{organizationId}. You are able to update
- Partner Organization ID (
partnerOrganizationId
) - Billing email address (
billingEmail
) - VAT ID (
vatId
) - Delivery Address for the physical cards (
deliveryAddress
) - Trade name (
tradeName
)
š” An organization may use a different name, e.g. for marketing purposes. In case a trade name is provided, this will be the one printed on the employees' physical cards, instead of the organization's legal name.
In addition to that it is now possible to turn on/off notifications and icons for missing receipts via the missingReceiptNotifications
property.
Update payment category (transactions)
When a transaction is created we assign a transaction/payment category to the transaction based on our internal mapping of merchant category codes (MCCs). Sometimes this does not fit consumers' needs. That's why we enable you to update the transaction/payment category for a single transaction via š PATCH /transactions/{transactionId}/category.
In the case of split transactions (accounting transactions), all split transactions will have a new category assigned.
Merchant logo & additional merchant data
This feature is only available in API Version
2.1.0
We start exposing cleaned-up merchant names (merchantData
.displayName
) and merchant logo data (merchantData
.logoPath
) from Pliants merchant database. We plan to add additional features hence we also start exposing the Pliant merchant ID (merchantData
.pliantMerchantId
).
In addition to that, we added additional data that we directly receive from the card processor like data that is part of the confirmation message (merchantRawData
.descriptionConfirmation
). This includes e.g. ticket numbers for airline bookings that we only receive with the second (confirmation) call. In the scope of this feature, we completely revamped the way how we expose merchant data for single/multiple transactions.
{
"mcc": "1234",
"mccDesc": "Test Merchant Description",
"merchantId": "123456789",
"merchantStreet": "Sonnenalle 42",
"merchantCity": "Vienna",
"merchantRegion": "AT",
"merchantPostcode": "1020",
"merchantCountry": "Austria",
"merchantPhone": "(123) 456-7890",
"merchantUrl": "https://www.dummy-merchant.com",
"merchantName": "Test Merchant Name",
"merchantLegalName": "Test Merchant Ltd.",
"merchantNameOther": "Test Merchant Name Other",
"merchantTaxId": "DE123456789",
"merchantContact": "[email protected]",
"merchantTerminalId": "1a2b3c4d"
}
"merchantData": {
"pliantMerchantId": "023ec4fb-1564-4fa1-8bd9-7b981601eae2",
"displayName": "Test Merchant",
"logoPath": "logos.getpliant.com/023ec4fb-1564-4fa1-8bd9-7b981601eae2.png?v=2"
},
"merchantRawData": {
"mcc": "1234",
"mccDesc": "Test Merchant Description",
"merchantStreet": "Sonnenalle 42",
"merchantCity": "Vienna",
"merchantRegion": "AT",
"merchantPostcode": "1020",
"merchantCountry": "Austria",
"merchantPhone": "(123) 456-7890",
"merchantUrl": "https://www.dummy-merchant.com",
"merchantNameOther": "Test Merchant Name",
"merchantLegalName": "Test Merchant Ltd.",
"merchantTaxId": "DE123456789",
"merchantContact": "[email protected]",
"merchantTerminalId": "1a2b3c4d",
"descriptionAuthorization": "Dummy Merchant Message",
"descriptionConfirmation": "Dummy Merchant 1234567"
}
This applies to the response payload of the following endpoints/callbacks:
Important
With this change we also deprecate the endpoint to fetch details for a single transaction in
2.1.0.
as this functionality is offered within the batch endpoint by providing a singletransactionId
.