| MobilePay Developer

Transaction Reporting API

With the transaction reporting API, you can quickly find all information associated with each of your payments, allowing you to concentrate on the important stuff while streamlining your financial reporting. MobilePay transaction reporting API allows to query all activities taking place at any of your MobilePay payment locations.

Reconciliation Flows

MobilePay's Transaction Reporting API is a major time and resource saver. All flows can be automated.

Example comparison flow

Find out more

Endpoint description on GitHub	Method
Transfer References	GET	Returns a list of completed transfer references for a payment point.
Transferred Transactions	GET	When a payment point transfer has been completed, you can retrieve a list of transactions that were included in the transfer. Maximum range is 365 days. If you do not know the transfer reference, it can be obtained from the endpoint above.
Transactions	GET	Returns a list of all transactions that took place during specified time period for a payment point.

GitHub Documentation

Review our documentation on Github* using the link below. here you find extended technical documentation

* GitHub is an external site which is not owned by MobilePay. MobilePay is not responsible for technical errors or downtime on GitHub.

Visit Github

What do we get out of the TRX api?

Value

Correct information, transparency and clarity. Some processes in banking are by nature asynchronous. You can guess and be correct often, but it will cost on support hours for you and your customer. By integrating and using the API, you take the guesswork out. From an architecture perspective, creating your own mirror database expecting a result is not advisable compared to querying a “single source of truth”. Sales and clearing are two different internal processes. As a merchant, you can sell, but the clearing is not always 100% matched to the sales. This is where the TRX API is highly useful.

How does it work?

A settlement pay out includes all your sales transactions from the previous day, net of refunds and fees. By using the API, you get a full list of all sales transactions and corresponding fees, totalling to the settlement on your bank account. You can reconcile your accounts with a high degree of data and transparency, moving your business towards always having up-to-date financial overviews. Note: if you chose to have fees invoiced, then the fees will not be deducted directly by MobilePay, and you instead need to reconcile against the invoices you receive. Invoiced fees are not visible in the API.

Transaction Reporting

With our transaction reporting API, we have developed endpoints to assist you, as an integrator and as a merchant in the reconciliation processes. The endpoints allows you to view core information about all the payments that the merchant has received from their customers.

Invoice Subscriptions

Payment Reference

If you have one of our MobilePay products, then you can expect to see a Payment Reference in your bank account. Payment reference is a reference that is assigned to payment and is visible in bank account statement when payment is completed and received by your bank. It is usually used for tracking and verifying which payments were received to the bank account (e.g. transfers).

MobilePay specific reference:

PCRRRRRRRRJJJDDMMYYX =>

PC =	Product code - Products need to identify the product, code is then put when generating the reference. 01 = POS 02 = MyShop 03 = Subscriptions 04 = Invoice 05 = AppSwitch 06 = Online
RRRRRRRR	= External Payment Point ID (length 8) (Myshop number, Pos LocationID....) - External Payment PointID will be sent in the payload from the product.The external payment point ID must be unique within the Merchant for the payment point. For Subscription and Invoice this will consist of 8 zeros (00000000).
JJJ	Running number (length 3)
DDMMYY	DDMMYY = Date (DDMMYY - lenght 6)
X	X = Check digit (length 1)

Example: 03000000000011602193 - which indicates Subscriptions payments received 16.02.2019.

Result Paging

Some endpoint queries can return a large number of results. In order to deliver them efficiently over the network, data pagination is used. Query responses which have more than 1000 transactions are automatically split into pages of 1000 records each.

A query of 859 transactions would produce a single page
A query of 1547 transactions would produce 2 pages
A query of 50000 transactions would produce 50 pages

When data pagination is used NextPageToken property is returned inside of request body. You should append the value of this property to query url pageToken parameter in order to retrieve the next page. If returned NextPageToken property is missing or null then the last page had been reached.

Important: NextPageToken value can contain any base64 characters, including/ +and =. Be sure to properly escape the value (by using url encoding) when submitting request for the next page.

Paging example

Initial query url is: https://api.mobilepay.dk/transaction-reporting/api/merchant/v1/paymentpoints/37b8450b-579b-489d-8698-c7800c65934c/transactions?from=2018-06-13T04:44:06Z&to=2018-06-13T23:00:00Z

Returned response is:

{
    "MerchantId": "123456789",
    "MerchantName": "Acme Ltd",
    "PaymentPointId" : "08b2f28f-9e5c-4416-ab5a-6338511c8ad1",
    "PaymentPointName" : "snack kiosk",
    "ReceiverAccount" : "DK123456789",
    "Transactions": [
        {
            "Type": "Payment",
            "Amount": 81.00,
            "CurrencyCode": "EUR",
            "CustomBulkId" : null,
            "Timestamp": "2018-06-13T04:44:06Z",
            "PaymentTransactionId" : "AABBCCDD11223344",
            "TransferReference" : "00020180624123456789",
            "TransferReferenceDate" : "2018-06-24",
            "SenderComment" : "This is fun",
            "CustomPaymentId" : "08b2f28f-9e5c-4416-ab5a-6338511c8ad1"
        },
        ...
    ],
    "NextPageToken": "CiAKGjBpNDd2Nmp2Zml2cXRwYjBpOXA"
 }

In order to retrieve the next page, you should call:

https://api.sandbox.mobilepay.dk/transaction-reporting/api/merchant/v1/paymentpoints/37b8450b-579b-489d-8698-c7800c65934c/transactions?from=2018-06-13T04:44:06Z&to=2018-06-13T23:00:00Z&pageToken=CiAKGjBpNDd2Nmp2Zml2cXRwYjBpOXA

Error codes

In general the following error codes are possible. Error messages from the API are always in English, and are intended for developers, rather than to be shown to end users.

Error Code	When to expect
400	for input validation errors. These will normally give detailed information including the specific parameters which were incorrect and examples of valid values where applicable. It is also returned if the query would yield too many results.
401	is returned when required authentication headers are missing from the request.
403	is returned for two cases: either user is not authorized to access specified resource or user is disabled.
404	is used in the case of trying to query non existing resource.
412	is used to indicate that resource exists but is not yet ready for use (for long running reports).
500	can happen if something unexpected goes wrong in the API, e.g. an unhandled exception. There is likely to be quite limited error information available in this case and it's best to contact MobilePay, providing details of what request caused the problem and when it was done. One form of 500 error that may be observed is a TimeoutException, which can ocurr when the API server did not receive an expected event after sending a command into the system to be executed. This error should be treated like other unhandled exceptions and reported, rather than ignored like a network timeout might be.

Get Started

Now that you have familiarized yourself with our Transaction Reporting API, you are now ready to get started.

Learn More