What's new with the Sprint API
We want to keep you informed. Stay up-to-date with the logged changes and improvements that we make to our API.
September 2022
These are the changes we’re making to our platform offerings this month.
1. AllocateCreateVirtualCard method added to Profile API
Type of update:
A new API call has been added to our Profile API product offering available in Africa
What’s changing?
The new method – AllocateCreateVirtualCard – creates a virtual card with specified amount loaded, linked to the specified profile and allocated to a cardholder with specified details
Who it affects:
All clients using the Profile API solution.
When is the change implemented?
This feature was deployed in September 2022.
What do you need to do?
No action required
Risk level:
Low –This is a not a breaking change
August 2022
These are the changes we’re making to our platform offerings this month.
1. Notification when Offline PIN is blocked
Type of update:
Issuers cardholders will be informed when their offline PIN is blocked
What’s changing?
Previously, Issuers were not notified when the offline PIN was blocked.
Who it affects:
All clients using the Offline PIN solution.
When is the change implemented?
This feature was deployed in August 2022.
What do you need to do?
No action required
Risk level:
Low –This is a not a breaking change
2. One version of the Daily Settlement report
Type of update:
We have moved onto one version of the Daily Settlement Report which users download.
What’s changing?
Previously, there were two version of the Daily Settlement Report. We have moved on to one single version of this report which contains all the information.
Who it affects?
All clients using the Sprint product
When is the change implemented?
This feature was deployed in August 2022.
What do you need to do?
No action required
Risk level:
Low –This is a not a breaking change
3. All “activation methods” supported on MDES
Type of update:
All “activation methods” are now available on the MDES tokenisation solution.
What’s changing?
We now support all activation methods as listed here
Who it affects?
All Companion clients using MDES and RemoteMessaging clients
When is the change implemented?
This feature was deployed in August 2022.
What do you need to do?
No action required
Risk level:
Low –This is a not a breaking change
February 2022
These are the two changes we’re making to our platform this month.
1. Inclusion of User-Agent Header in all API requests
Type of update:
Paymentology requires a User-Agent header to be included in every request to its API services.
What’s changing?
You are required to include a User-Agent header in every request to our API services.
Who it affects:
All clients using Card and Companion APIs.
When is the change implemented?
This feature will be implemented on 17 February 2022.
What do you need to do?
You will need to ensure that the a User-Agent header is included in all API requests. Read more here
Example:
(application, version and programming lang),
User-Agent: <product> / <product-version> <comment>
Risk level:
High—this is compulsory. Any request without a User-Agent header shall be denied.
2. We’re enhancing the data provided for 3D Secure transactions
Type of update:
We are enhancing the data provided for 3D Secure transactions
Who it affects?
All clients using Remote Messaging API 3DSecure.OTP method
Risk level:
Low – This is a no breaking change
Why we’re making this change?
-
To make it easier to match up 3D Secure transactions with their relevant OTPs
-
To provide more visibility around attempted/declined 3D Secure transactions
What is this change about?
To enable our 3D Secure clients to receive the additional information above the current data ‘messageType’, ‘trackingNumber’, ‘customerReference’ and ‘challenge’.
New additional data;
-
MerchantDescription
-
TransactionAmount
-
CurrencyCode
Once effective, you will be receiving:
-
MessageType
-
TrackingNumber
-
CustomerReference
-
Challenge
-
MerchantDescription
-
TransactionAmount
-
CurrencyCode
What do you need to do?
Ensure that, as per our guidelines, receiving additional data will not break your implementation. The additional data should be dynamically parsed, and fields you are not using should simply be ignored.
When will this be available?
The change will be available in the production environment by 10 March 2022.
June 2021
These are the two changes we’re making to our platform this month.
1. Inclusion of TRID in KLV Data in MDES Admin Messages
Type of update:
Clients will now receive TRID (Token Requestor ID) in the KLV data in MDES Admin messages sent to a wallet during the tokenization process.
What’s changing?
You can now receive TRID in the KLV data in MDES Admin Messages. TRID is a unique numeric value that identifies the token requestor.
Note that clients who launch MDES tokenization services with XPay wallets are required to comply with the Mastercard Mandate to support M4M (MDES for Merchants) and Token Connect capabilities.
Who it affects:
All clients who are integrating with MDES using Card and Companion APIs.
When is the change implemented?
This feature was released on 2nd June 2021.
What do you need to do?
Since the KLV field parameter is optional, you can liaise with your Client Executive if you need the field to be enabled for your card program. After the field is enabled, you’ll start receiving the TRID data.
Risk level:
Low—this is an opt in feature.
2. Ability to Update Expiry Dates of Virtual Cards
Type of update:
Clients will now be able to update the expiry dates of Virtual Cards using a new API method called UpdateExpiryDate.
What’s changing?
You can now request the expiry date of a Virtual Card to be updated to a future date of your choice. Remember that you cannot request a date that has already passed.
Who it affects:
All clients using the Card API.
When is the change implemented?
This feature was released on 2nd June 2021.
Is there a sample?
The UpdateExpiryDate method is available on Paymentology’s Sprint developer portal in the API reference section. You will find the XML sample request and response under the method.
What do you need to do?
This is an optional change that you can only apply to Virtual Cards. It does not apply to Physical Cards.
Risk level:
Low— this is an opt in feature.
May 2021
New documentation available:
- Paymentology supports AFD Transactions on the Sprint platform. Read more on AFD Transactions here
- Read more on Dispute Handling here
These are the changes we’re making to our platform this month.
1. Update to Visa Settlement Report availability
Type of update:
Visa Settlement Report is now available by BIN and SRE for clients with multiple BINs and SREs.
What’s changing?
You can now view the Visa Settlement Report by BIN (Bank Identification Number) and SRE (Settlement Reporting Entity). There will be three tabs for viewing the report—BIN, SRE for local currency account, and SRE for international currency account). This will be available for clients who have multiple BINs or SREs only. If a client has one BIN or SRE, there will only be one tab on the report.
Who it affects:
All clients integrating with Visa using Card, Companion, and Profile APIs.
When will the change be implemented?
26 May 2021 at 20:00 UTC.
Is there a sample report?
A sample report can be found here
What you need to do:
Ensure your automated processes using these files can handle the additional tabs.
April 2021
We’re implementing the following changes to enhance the capabilities of our platform and ensure making payments is better and smoother.
1. Inclusion of populated data on the Visa Daily Settlement Report
Type of update
Visa Daily Settlement Report now includes populated interchange amounts per line of a transaction.
What’s changing?
You can now view populated data on the interchange column of the Visa Daily Settlement Report—just like on the Mastercard Detailed Settlement Report. The column was previously empty.
Who it affects:
All clients integrating with Visa using interchange (forex) fees on Card and Companion APIs.
When will the change be implemented?
20 April 2021 at 20:00 UTC.
Is there a sample report?
A sample report is available here. You can use it to prepare for the change.
What you need to do:
No action required.
Risk level:
Low – no action required
2. Inclusion of Digitized Wallet ID on the Failed Authorization Report
Type of update:
Digitized Wallet ID is now available on the downloadable Failed Authorization Report.
What’s changing?
You can now view the Digitized Wallet IDs for the respective Xpay wallets. There will be a new column at the end of the Failed Authorization Report called “Digitized Wallet ID”, which will contain a numeric 3-digit code representing the relevant Xpay app.
Who it affects:
All clients integrating with MDES (Mastercard Digital Enablement Service) using Card, Companion, and Profile APIs.
When will the change be implemented?
4 May 2021 at 20:00 UTC.
Is there a sample report?
A sample report is available here. You can use it to prepare for the change.
What you need to do?
Ensure any further processing completed on the files by your systems will not have issues from the addition of an extra column.
Risk Level:
High—this is a breaking change requiring your immediate action.
March 2021
- We’re adding a Transaction Internal Response Code to the Failed Transaction Report
Who it affects:
All Companion API clients
Risk level:
Low – This is a no breaking change
Why we’re making this change:
A number of internal response codes get overwritten before responding to the card scheme due to restrictions around the response codes we are permitted to use for various types of payments.
What is this change about:
We’re adding an additional column to the Failed Transaction Report to give clear information about the cause of transaction declines. Here we will display both the response code that we send back to the card scheme, as well as the code that was used for processing internally.
Example:
An internal code of 1800 (invalid 3D Secure data) will be overwritten with 1022.
What you need to do (updated):
Make preparations for an additional “Transaction Internal Code” column, as the final column, after the “POS Entry mode” column (column 14).
How do you test this change:
You can download a sample report to prepare for the change.
When will this be available:
The change will be deployed to the live environment by 1 April 2021 at 2 PM CET (updated)
- We’re enhancing data provided for 3D Secure transactions
Who it affects:
All clients using Dynamic 3D Secure
Risk level:
Low – This is a no breaking change
Why we’re making this change:
- To make it easier to match up 3D Secure transactions with their relevant OTPs
- To provide more visibility around attempted/declined 3D Secure transactions
What this change is about:
To enable our 3D Secure clients to receive the additional information within our Admin Message OTP API.
Previously there was only an OTP in the MessageData field of the “AdministrativeMessage3DSecureOTP” call. Now we are adding the extra KLV data in the MessageData field of the “AdministrativeMessage3DSecureOTP” call:
- tracking number – KLV002
- original transaction amount – KLV004
- original currency code – KLV049
- Merchant Name – KLV043
What you need to do:
This feature needs to be activated by your Paymentology Client Executive. Ensure that, as per our guidelines, receiving additional KLV data (besides the KLV900) will not break your implementation. The KLV data should be dynamically parsed, and fields you are not using should simply be ignored.
When will this be available:
The change is available on ve.uat currently and will be available in the production environment by 25 March 2021 at 2 PM CET (updated) however the change will only take effect if the program is set up for it. Hence If your system is expecting to receive the new KLV information, please ask your Client Executive to enable the KLV mentioned in your campaigns.
- We’re making changes to the Capture Mode of transactions
Who it affects:
All clients using KLV 250
Risk level:
Low – This is a no breaking change
Why we’re making the change:
To help our clients identify what type of MDES transaction has been completed so that they can better support their cardholders with disputes and chargebacks.
What this change is about:
-
- The KLV field 250 will no longer show “3DS” or “MDES” in these types of transactions
- The KLV field 250 will reflect the original POS entry modes, such as MAG, MAN, EMV, OB, NFC, ADJ
- We will be introducing a new KLV field (KLV 262) to identify the transaction as “3DS” or “MDES”
- If the transaction is not a “3DS” or “MDES” transaction, this field with be left blank or empty, though you should be prepared to accept additional types in the future
- The KLV field will need to be selected by the Client Executive to receive the KLV fields listed above on the campaign
| Scenario | KLV Code (250) | Identifier (KLV 255) | KLV Code (262) | |
|---|---|---|---|---|
| FPAN | Manual transaction (a whitelist merchant) | MAN - Manual (Manually inputted into Terminal) | empty or not sent | empty or not sent |
| E-commerce transaction | ECOM | empty or not sent | empty or not sent | |
| DPAN | Token for Merchant | ECOM | M4M | MDES |
| In App Payment; Apple Pay | ECOM | Apple Pay | MDES | |
| In App Payment; Samsung Pay | ECOM | Samsung Pay | MDES | |
| In App Payment; Google Pay | ECOM | Google Pay | MDES | |
| NFC via Apple Pay | NFC | Apple Pay | MDES | |
| NFC via Samsung Pay | NFC | Samsung Pay | MDES | |
| NFC via Google Pay | NFC | Google Pay | MDES | |
| 3DS | 3D Secure Transaction | ECOM | empty or not sent | 3DS |
What you need to do:
This feature needs to be activated by your Paymentology Client Executive. Ensure that, as per our guidelines, receiving additional KLV data (besides the KLV900) will not break your implementation. The KLV data should be dynamically parsed, and fields you are not using should simply be ignored.
When will this be available:
The change is available on ve.uat currently and will be available in the production environment by 25 March 2021 at 2 PM CET (updated) however the change will only take effect if the program is set up for it. Hence If your system is expecting to receive the new KLV information, please ask your Client Executive to enable the KLV mentioned in your campaigns.
February 2021
Security – We have updated our Security policy to include information on requirements for User-Agent Header information and expected traffic disclosure.
Messages – We have added more info on the message types for the Administrative messages that Paymentology will send to the client for Tokenization.
Fraud and Risk – We have added a new section with information about our Fraud and Risk protocols.
QR Payments – We have updated our QR payments section to with more information on this service and how it works.
January 2021
Client Testing Guide – We have added a comprehensive guide on testing with the Paymentology Sprint Implementations team with downloadable Test scripts and a link to book a meeting with someone in the Testing team.
Reports – We have updated our Reports sections for each API with detailed descriptions of the information sent on the main Reports Paymentology has available for the Sprint platform.
Tokenization – We have added a clearer explanation on how Paymentology supports Tokenization on the Sprint Platform and how this works with more information on Manual Provisioning and Push Provisioning.
API Reference documentation updates
Updated parameters in LoadReversal (QR RI – Remote), OrderCard, Deduct, DeductAdjustment and DeductReversal methods to offer more accurate and informative details
Was this page helpful?