FAQ

This section will include answers to questions that were raised during the integration process. Please have a look below to see if your question is included. If not, please contact terminalapi@worldline.com

• How do I obtain an API key?

  API keys can be requested via email by contacting the support team. Ensure that you securely store or delete the email containing the API key to prevent unauthorized access.

• How do I use the API key?
  Please use an Authorization header with value "Bearer <YOUR API KEY>"

• What environments are available for testing and production?

  The API provides integration and production environments. Use the integration environment for testing purposes with a development terminal to simulate real-world transactions.

• Is the Terminal API PCI compliant?

  Yes, the API is PCI DSS compliant. No unmasked PCI-related data is accessible through the API, reducing compliance risks.

• What should I do if I encounter an authentication error?
  Verify that your API key is correct and active. Ensure that the request headers include proper authentication details and that you are using the correct environment URLs.

• Can I simulate transactions without affecting real data?

  Yes, use the integration environment for testing transactions. It allows you to simulate scenarios without impacting production data.

• Reversal - when I revert a transaction, the terminal currently asks for the password. Is this always mandatory, also in production mode?

  The password is mandatory when the terminal is set up in standalone mode. It is a limitation of the working mode of the terminal itself that cannot be bypassed by Terminal API.

  If you want to avoid password, it is better to set the terminal up in ECR Integrated mode, but then you need to print the receipts yourself.

• What is CardAcquisition used for? For which use case do I start a transaction like this?

  The common use case is for cardholder identification without an additional transaction. We would recommend to use the normal payment transaction instead of using CardAcquisition unless your use case requests a two-step transaction.

• What is the ExchangeIdentification is used for and what I have to put in this field?

  This a field that you can use to identify the request, it's useful for supporting you in case of problems, think of it as a tracing id.

• Abortion - AbortReason: is there a list of possible values, or is any text allowed? 

  Yes any string is allowed.

• TransactionReference - is there any restriction or recommendation how to use this field? Could I send the invoice identification?

  We recommend a usable value, the invoice is a valid choice.

• Is there any specific request for only reverting the last transaction? Is it the "Sale Service - Reversal" ?

  Yes, please use the Reversal request for this.

• Is there any up-to-date overview of the existing types?

  We are working on an improved developer portal, but for now you can use this list:

  • SAAP: Admin Response

  • SDDR: Device Request

  • SDDP: Device Response

  • SSEN: Event Notification

  • SSMQ: Message Status Request

  • SSMR: Message Status Response

  • SSRJ: Rejection

  • SARQ: Report Request

  • SARP: Report Response

  • SFRQ: Sale Financial Reconciliation Request

  • SFRP: Sale Financial Reconciliation Response

  • SFSQ: Sale Financial Service Request

  • SFSP: Sale Financial Service Response

  • SASQ: Session Management Request

  • SASP: Session Management Response