Generation and Transportation of Transaction Documents using

Payment Infrastructure

Gatis Vitols

, Nikolajs Bumanis

and Irina Arhipova

Faculty of Information Technologies, Latvia University of Agriculture, Jelgava, Latvia

Ltd ”Mobilly”, Riga, Latvia

Keywords: Mobile Payments, Smartcards, Transaction Documents, Transaction Messages.

Abstract: Mobile payments are rapidly increasing during e-commerce transactions. Industry has well established

procedures how to process the payments. However processes of management of transaction documents (e.g.

warranty cards, insurance policies, etc.) are still undeveloped and raise issues of information system and

document format fragmentation. This paper address transaction document management issue with

introduction of improvements in payment procedures, such as transaction processing using multiple

payment methods for single payment, point of interaction dividing into elements for further dividing of

needs for associate parties, transaction messaging schemes, which can be used for transportation of

transaction documents. Aim of this research is to propose improvements of payment processing process

models by introducing generation and transportation of transaction documents using unified documents and

concepts. Improved procedures are further planned to implement in micropayment company payment

processing processes for approbation. The results show that distribution of transaction document into

multiple types provides the ability to track generation steps of transaction documents and to correspond

these steps with transaction processing results and messages, by therefore making these two non-connected

before processes as whole new global service processing process. Proposed improvements of mobile

payment infrastructure support creation and management of transaction documents using unified documents

and concepts.

1 INTRODUCTION

Management of transaction documents is important

and challenging process in e-commerce. Examples

of transaction documents are bills, warranty cards,

bank statements and insurance policies. Transaction

documents have various lifecycles. Most of the

documents are valid and used only during

transaction or short while after transaction. However

some transaction documents (e.g. warranty cards,

medical receipts) have to be kept safely for multiple

years and some may be submitted to other party,

such as tax refund documents.

Typically transaction documents are generated

during or after payment transaction. Recently mobile

and NFC payments are used more frequently and in

future application of such payments can rapidly

increase (Oliveira et al., 2016). To execute mobile

payments, external payment methods are integrated

into mobile applications, usually raising issues of

fragmentation of payment processors and entities

that perform generation and transportation of

transaction documents.

Fragmentation of payment and transaction

document managers further leads to multiple issues

for users, such as various transportation methods,

formats and platforms such as e-mails, information

systems, SMS and others (Bojjagani and Sastry,

2015).

Integration of existing online payment methods

(e.g. Paypal, Google Wallet, Stripe) into mobile

payment systems partially allows solving

fragmentation issues. However such integration is

possible only in certain cases and raise the risks of

data integrity and security (Preibusch et al., 2016).

In e-commerce industry transaction document

generation and transportation is mostly detached

from payment processing and includes only

transaction documents containing transaction

processing result data. For payment processing,

typically concepts and models introduced by

financial service companies VISA (IBM, 2011;

Vitols, G., Bumanis, N. and Arhipova, I.

Generation and Transportation of Transaction Documents using Payment Infrastructure.

DOI: 10.5220/0006356307390744

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 739-744

ISBN: 978-989-758-248-6

739

VISA, 2012) and MasterCard (Mastercard, 2016) is

used.

Aim of this research is to propose improvements

of payment processing process models by

introducing generation and transportation of

transaction documents using unified documents and

concepts.

2 PROPOSED IMPROVEMENTS

FOR TRANSACTION

DOCUMENT MANAGEMENT

Standard banking procedures focus on transaction

processing, whereas main problems of other

payment infrastructures (e.g. micropayment, mobile

payments) development lie in transaction document

generation and transportation, including transaction

initializing based on these transaction documents.

Therefore it is necessary to identify systems as

processing partners, which would be able to develop

and maintain all functionality required to perform

any type of transaction. Additionally it is necessary

to precisely determine the ratio between generation

and transportation of transaction documents and

improvements for existing standard banking flows to

implement such integrated processes (Fig. 1).

Figure 1: Proposed role distribution in mobile and

smartcard payment infrastructure (Vitols et al., 2015).

The mutual interaction between roles of mobile

payment infrastructure was proposed in previous

research (Vitols et al., 2015), where focus was put

on execution of mobile payments using multi-

application smartcards (Bumanis, Vitols, et al.,

2014). Classic e-commerce payment processing

schemes includes such roles as client, merchant,

issuer, acquirer and intermediate organization, which

provides routing functions, for example,

MasterCard. The following mobile payment

infrastructure roles were introduced:

 concentrator, entity which performs intermediate

organization's functionality, manages contractual

and identification registers for associate parties,

manages transaction document transportation

mechanism and provides protocol for its usage;

 smartlet manager is responsible for smartlet

creation, issuing and life cycle management, and

point of interaction creation and management;

 distributor orders smartlet, stores and manages

client database;

 client as smartlet user;

 smartlet, where smartlet is a device with payment

initiation capabilities, for example, smartphone

or smartcard;

 provider, including payment provider and service

provider, where payment provider is responsible

for acceptance and processing of transactions.

Service provider is managing point of interaction

and physical or virtual point of sales meant for

purchases of this service provider's products.

During research following functions were

proposed:

 payment acceptance;

 payment authorization and clearance;

 smartlet identification and authorization;

 client authorization;

 generation of transaction documents.

Specialized methods were identified for payment

providers, assuming one payment provider may

perform either one or both methods. Respectively

those are payment method and processing method,

where payment method is responsible for accepting

and processing transactions, but processing method

would be used in case if additional calculations are

required, such as subsidy administration, or/and

changes to client accounting system's data must be

done (Bumanis, Zacepins, et al., 2014).

Main proposed improvements of this research are

transaction processing using multiple payment

methods for single payment, addition of

functionality for point of interaction and transaction

messaging schemes, which can be used for

transportation of transaction documents.

Transaction documents are documents created in

the process of realization of particular service, where

documents are used for initiation of one or multiple

transactions, as well as for transaction result

verification (Bouazzouni et al., 2016).

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

740

Transaction documents for different services and

products may require different unique data. In this

case the format of transaction documents must

comply with formatting requirements for ordering of

particular service, for example, the ticket ordering

requires trip time and station names, and whereas

paying for parking spot require auto number and

start time. It is inefficient to use unique formats of

transaction documents for each individual service

while implementing various services into one

system. Therefore, it is necessary to develop

subsystem, which would be able to transform

ordering data of various services into unified

transaction document format to manage these

objects. For this point we propose the usage of your

country specified requirements for electronic

document formats. In Latvia, for reference, such

requirements are described by law accepted by

cabinet of ministry (Cabinet of Ministers and

Republic of Latvia, 2014), stating the usage of XML

definition format and XSD scheme for its validation.

Each service, offered by service providers,

requires point of interaction for transaction

initiation. Point of interaction can be accessed from

client's device, such as smartphone's application or

internet web store. Transaction initiation is

performed by point of sale connection to this point

of interaction, where point of sale corresponds to

particular payment method. Whereas implementing

multiple payment methods in the way of payment

instruments into single point of interaction results in

potentially longer usage time. Researchers identified

(Kujala et al., 2017) that prolonged usage is based

on client's positive expectations before service

platforms usage and realization of those expectation

during exploitation time. As improvement, point of

interaction was divided into two forms - service

ordering form and payment form, respectively

named, sPOI and pPOI (Fig. 2).

Figure 2: Smartlet POI components.

Firstly, functionality of sPOI includes inputting

parameters for service ordering, performed by client,

for example - providing auto number for parking

spot ordering service realization. Secondly, pPOI

provides access to service specified payment

instruments, which together form a payment

combination. Technically, pPOI is interface to point

of sales with particular payment methods.

Model of transaction document mechanism is based

around different objects, including price matrix,

payment combination, payment instrument, user

interface of payment combination authorization and

payment instrument authorization (Fig. 3).

Figure 3: Model of transaction document mechanism.

Four transaction document types were defined for

transaction document mechanism:

 Order - document, defining service ordering data

and service provider's identification and

authorization parameters in unified specified

format;

 Payment Order - document, defining necessary

data for initiation of one or multiple transactions,

including payment amount;

 Payment Receipt - document, generated after

transactions are performed and contains result of

processing these transactions;

 Receipt - document, which includes all data

regarding performed payment, including

completed transactions.

2.1 Sequence for Generation Process

Generation of transaction documents is performed

by service’s POI components - sPOI and pPOI. Each

service has own unique POI. When client inputs

ordering parameters and presses "Order" button

sPOI generates transaction document "Order", which

is then along with price matrix is sent to pPOI for

processing. In result, pPOI modifies the price matrix

according to accessible payment instruments and

generates the transaction document named "Payment

Order", after which client must choose one or

multiple offered payment instruments, basically, the

Generation and Transportation of Transaction Documents using Payment Infrastructure

741

currency, for example, cash or bonus points, for

order payment. By pressing button "Pay" client

authorizes transaction initiation. Transactions are

initiated for each payment method corresponding to

selected payment instruments, by respective point of

sale, either physical point of sale, virtual point of

sale or EMV (Europay, MasterCard, and Visa)

payment application. According to transaction

processing results pPOI generates transaction

document named "Payment Receipt". "Payment

Receipt" is generated for both, successfully and

unsuccessfully completed transactions, where in

case of unsuccessfully processed transaction client

may be prompted to choose different payment

instruments and repeat the payment process. When

payment is successfully completed, pPOI sends

transaction document named "Payment Receipt" to

sPOI, which in result generates transaction

document named "Receipt" in unified format for

storage in the client's profile and further usage by the

client. Transaction document "Receipt" is saved

based on sPOI settings defining necessity to save

transaction documents in distributors system or on

smartcards.

2.2 Transportation Flow

Generation and transportation of transaction

documents are performed in close collaboration with

transaction processing using payment provider

system's mechanisms (Fig. 4). Implementation of

transportation functionality as part of transaction

processing requires some sort of message routing

between partners. Existing payment processing

organization's schemes includes subsystems

providing transaction data routing between partners

incorporated in transaction processing, as well as

providing authorization functionality. MasterCard

organization uses system called MasterCard

Network (Mastercard, 2016), providing routing

between issuer and acquirer, whereas Visa

organization's system VisaNet (IBM, 2011; VISA,

2012) in addition to routing function is responsible

for clearing and settlement. Based on how these

organizations route transaction data between

partners we concluded the necessity of hub type of

system’s component or subsystem. Therefore, such

element was introduced named "TRX Router" (see

Fig 4). "TRX Router" was implemented as payment

provider's payment method system's component,

which is responsible for routing transaction data and

transactional message to processing method and

authorization performing systems. Functionality of

this hub is based around messaging flow with both

entry and exit nodes, identified as:

 processor gate for processing system and its hub

"Processing Router";

 point of interaction (POI) gate for device, used

for payment initiation;

 authorization gate for client and transaction

authorization.

Connection between systems is implemented by

using gates and corresponding interfaces. Processing

method used when additional calculations, such as

government subsidy calculations or automatic

money account balance increment, are required, uses

hub named "Processing Router", which is connected

to partner systems using following entry and exit

nodes:

 processor gate for external processing system;

 TRX gate for payment method and its hub "TRX

Router";

 smartlet manager gate for smartlet manager's

system;

 accounting gate for client's accounting system.

Implementation of transportation mechanism

where multiple hubs of various partners are used

requires usage of unified easy-to-identify format for

both transaction messages and transportation of

transaction documents. Proposed solution uses

transaction messaging system as platform for

transportation of transaction documents, and

therefore message types must be identified.

Figure 4: Proposed transportation flow between payment

method and processing method.

Payment and processing method specialized

messages were named as "TRX Message". Two

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

742

types of messages were defined: Request, which is

used for request message and Response, used for

answer message. Response always uses Request as

reference message, so hubs can easily identify

message sources. We propose following message

actions:

 Authorize - request type message for

authorization;

 Capture - request type message to execute

transaction capture;

 Cancel - request type message to cancel

transaction processing;

 Accepted - response type message, indicating

successful authorization of transaction in

particular system or subsystem;

 Approved - response type message, indicating

approval of transaction execution;

 Canceled - response type message, indicating

cancelation of transaction due to particular

technical reasons, including timeout;

 Denied - response type message, indicating

declining of transaction due to particular reasons.

3 DISCUSSION

Proposed payment infrastructure allows

implementing transportation of transaction

documents along with transaction messages;

however for functionally comprehensive transaction

document management separate system must be

developed. This system would work in collaboration

with transaction messaging system and in the same

time would be responsible for generation and

transportation of transaction documents which are

not necessary related to transaction processing

partners, for example, distributor. Separate system

will allow realization of transportation for informal

messages as well, for example, reports.

Usually by integrating multiple e-commerce

systems difficulties with transaction document

formats (Mitasiunas and Bykovskij, 2015) may

occur; however, electronic document format

(Wawrzyniak and El Fray, 2016) will be available to

each system in unified structure, containing five

components - abstract, XML data, JavaScript

methods, CSS/HTML5 and mandates. Our proposed

document structure provides both data and

functionality, therefore we believe it will suit e-

commerce needs.

As additional improvements message format is

proposed, which is built around two parts - header

and body, providing possibility to transport and

process messages by every system with inclusion of

unique data required by each different service. In

this case document body part is responsible for

handling service specified data, in other words body

is transaction object, whereas document header

contains necessary information for message routing.

Verification and validation of these messages is

done during implementation phase using XML and

XML scheme 1.1, whereas authorization is realized

by encapsulating XML formatted message into eDoc

container. Using both eDoc and XML provides

secure transportation of transaction documents.

These improvements allows interoperating of

different transaction documents for various services,

provides ease of transportation using one messaging

system, which transfers both formal and informal

messages. This allows usage of unified format for

transaction documents to store and later manage

them by different parties and systems.

4 CONCLUSIONS

Distribution of transaction document types provides

the ability to track generation steps of transaction

documents and correspond these steps with

transaction processing results and messages, by

therefore making these two non-connected before

processes as whole new global service processing

process.

Standard banking procedures typically does not

provide processes for transportation of transaction

document and focus mainly of payment processing.

Existing payment processing workflows and

payment infrastructure allows usage of entities such

as banks to provide secure client authorization in

case client uses bank account.

Proposed transportation mechanism describes

mostly transaction messages used during transaction

processing, however it potentially can be used for

transportation of transaction documents between

transaction processing partners. During the research

it was concluded, that transportation of transaction

documents requires delivering message to additional

parties, therefore separate system must be

developed, which could use unified formats for both

transaction documents and transportation messages.

Proposed improvements of mobile payment

infrastructure support creation and management of

transaction documents using unified documents and

concepts.

Generation and Transportation of Transaction Documents using Payment Infrastructure

743

ACKNOWLEDGEMENTS

The research leading to these results has received

funding from the research project "Competence

Centre of Information and Communication

Technologies" of EU Structural funds, contract No.

1.2.1.1/16/A/007 signed between IT Competence

Centre and Central Finance and Contracting Agency,

Research No. 1.4 “Development of personified

transaction document management model". More

information at http://www.itkc.lv/?lang=en.

REFERENCES

Bojjagani, S. & Sastry, V.N., 2015. SSMBP: A secure

SMS-based mobile banking protocol with formal

verification. In Wireless and Mobile Computing,

Networking and Communications (WiMob).

Bouazzouni, M.A., Conchon, E. & Peyrard, F., 2016.

Trusted mobile computing: An overview of existing

solutions. Future Generation Computer Systems, (In

press).

Bumanis, N., Vitols, G., et al., 2014. Service Oriented

Solution for Managing Smartlets. Procedia Computer

Science, 43(1), pp.33–40.

Bumanis, N., Zacepins, A. & Arhipova, I., 2014.

Administration of government subsidies using

contactless bank cards. In S. Hammoudi, L.

Maciaszek, & J. Cordeiro, eds. ICEIS 2014 -

Proceedings of the 16th International Conference on

Enterprise Information Systems. Lisbon: SciTePress,

pp. 128–132.

Cabinet of Ministers & Republic of Latvia, 2014. The

rules on the tax and other payment registration

electronic devices and equipment for the technical

requirements. Available at: http://likumi.lv/doc.php?

id=265486.

IBM, 2011. IBM Knowledge Center - VisaNet overview.

Available at: http://www.ibm.com/support/

knowledgecenter/SSZLC2_6.0.0/com.ibm.commerce.

payments.developer.doc/concepts/cpyvitalmst04.htm

[Accessed November 19, 2016].

Kujala, S., Mugge, R. & Miron-Shatz, T., 2017. The role

of expectations in service evaluation: A longitudinal

study of a proximity mobile payment service.

International Journal of Human-Computer Studies,

98, pp.51–61.

Mastercard, 2016. Mastercard Payment Processing |

Extended Processing Services | Merchant Transaction

Process. Available at: https://www.mastercard.us/en-

us/about-mastercard/what-we-do/payment-

processing.html [Accessed November 17, 2016].

Mitasiunas, A. & Bykovskij, A., 2015. Lithuanian national

platform of electronic documents: Towards cross-

border interoperability. eChallenges e-2015

Conference Proceedings.

Oliveira, T. et al., 2016. Mobile payment: Understanding

the determinants of customer adoption and intention to

recommend the technology. Computers in Human

Behavior, 61, pp.404–414.

Preibusch, S. et al., 2016. Shopping for privacy: Purchase

details leaked to PayPal. Electronic Commerce

Research and Applications, 15, pp.52–64.

VISA, 2012. VisaNet The technology behind Visa,

Available at: https://usa.visa.com/content/dam/VCOM

/download/corporate/media/visanet-technology/visa-

net-booklet.pdf [Accessed December 12, 2016].

Vitols, G. et al., 2015. Multi-payment solution for smartlet

applications. In H. Slimane, M. Leszek, & E. Teniente,

eds. ICEIS 2015 - Proceedings of the 17th

International Conference on Enterprise Information

Systems. Barcelona: SciTePress, pp. 668–673.

Wawrzyniak, G. & El Fray, I., 2016. An electronic

document for distributed electronic services. Lecture

Notes in Computer Science, 9842(LNCS), pp.617–

630.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

744