Guides
Client Login

FAQ's

FAST transaction interface FAQ's

How is FAST setup?

Your FAST URL is added and configured internally by Paymentology during initial implementation.

This is discussed and performed during the first two phases of implementation.

Is FAST available in UAT?

You can provide a URL you wish to use for FAST UAT, which is then added and configured internally by Paymentology. This will connect your testing environments to our UAT, enabling end-to-end testing.

This is discussed and performed during the first two phases of implementation.

What does FAST stand for?

FAST is an acronym for Framework for Authorization and Settlement Transmission.

FAST is the real-time transaction interface of Banking.Live.

Is it possible to have more than one FAST feed?

Many clients choose to utilize more than one FAST feed. Typically, this is set-up as:

  1. the first FAST feed is used in Active mode allowing you to take the final approve/decline decision on a transaction.
  2. the second FAST feed is used in Passive mode, allowing you to bare witness to the transaction once the decision has been taken. This second Passive feed is used to feed straight into the your Enterprise Data Lake or similar.

What's the difference between Active and Passive FAST modes?

Active FAST enables you to take the final approve/decline decision on a transaction. Banking.Live receives the authorization message from the card network and parses it to you in real-time. Once you receive this FAST request message from Banking.Live, you perform your checks (including financial - as you hold the Store of Value) and provide the reason for the approve/decline decision you've taken in the FAST response message. Banking.Live then responds to the initial card network authorization message with this decision/reason.

In Passive mode, Paymentology takes the final approve/decline decision on a transaction for you. Banking.Live receives the authorization message from the card network, processes the message and performs checks (including financial - as we hold the Store of Value). You then recieve a FAST transaction message moments after we've responded to the card network. This FAST message will also include the decision we've taken.

What message standard does FAST follow?

FAST is based off the ISO8583 standard.


Remote messaging FAQ's

What is the process to enable remote messages?

All remote message endpoints are added and configured by Paymentology during phases of your initial implementation. Our Implementation Team discusses these with you at the time.

  • If you are already live with Paymentology, then you can raise a request through our Customer Support platform or your Client Executive.
  • You will need to make sure that you can consume the remote messages. You can refer to the message specifications for each type of remote message:
    • For FAST passive specifications, you can refer here.
    • For Card Status Updates specifications, you can refer here.
    • For Tokenization Notifications, you can refer here.

Are there different endpoints for remote messages?

You can choose to use a different endpoint for remote messages. You can discuss this with us at any time.

Are these messages sent in an end of day report?

Paymentology sends you remote messages for you to conusme, manage and store the data sent for your own internal use and reporting.

Once you receive these remote messages, it is up to you to manage and store the data. We will not resend these messages to you at a later time.

What is the purpose of remote messages?

Remote messages provide you with real-time notifications of changes, updates or transactions made on cards. Major benefits of remote messages are:

  • being able to inform your cardholders via App of the status of their cards.
  • better management of fraud and risk.
  • having a real-time view of how your cardholders are using your product.

Reports FAQ's

How do we access a report?

Most reports are accessed via SFTP, others are sent via email. SFTP details would have been shared and configured during initial implementation.

You can check how to access a specific report by checking the Stored in: field published on each report guide.

If you are not receiving a report and wish to, you can raise a request via our Customer Support platform.

Can we request changes to a report?

Paymentology has built Banking.Live reports to include all the information you need for the reports purpose. You will find if a report is missing a detail you believe is necessary, that this detail will be available on a different report.

Can we have historical/old reports sent again?

Once you receive a report, it is best practice to store this in a place where you can access it again. Reports not downloaded will not be generated by Paymentology after the guaranteed retention period of three months.

You can refer here for more information.


API's FAQ's

What security measures do you have in place to secure your APIs?

Banking.Live API's use multiple security measures and protocols to ensure all data transmitted is fully secure. You can read all about our API security here.

What API version should we use?

As a new client you should be integrating with all the latest versions of our API endpoints.

Are Banking.Live API's idempotent?

Most of our API's are idempotent. You should always check the specific API endpoints' specifications to confirm that it is idempotent. The specification will state that it is idempotent.

Updated 7 months ago