Xmldefs

Realauth XML Definitions Guide
Version 1.3
Table of Contents
Table of Contents................................................................................................................................................................... 1
Table of Contents................................................................................................................................................................... 2
Introduction to Realex Payments ......................................................................................................................................... 3
1 Realex Services .............................................................................................................................................................. 4
2 Introduction ................................................................................................................................................................... 4
3 Requests ......................................................................................................................................................................... 5
3.1 Auth Request Type ..................................................................................................................................... 5
3.2 Manual Request Type ............................................................................................................................... 8
3.3 Offline Request Type............................................................................................................................... 11
3.4 Rebate Request Type .............................................................................................................................. 13
3.5 Void Request Type.................................................................................................................................... 15
3.6 realscore Request Type......................................................................................................................... 16
3.7 Settle Request Type................................................................................................................................. 17
4 Responses ..................................................................................................................................................................... 19
4.1 Result codes that will return full responses............................................................................ 19
4.2 Result codes that will only return code and message....................................................... 19
4.3 Response Format....................................................................................................................................... 20
5 Contact details. ............................................................................................................................................................ 22
Appendix A – Version Control............................................................................................................................................ 22
Page 2 - Version 1.2.2 Printed on: 21 Jun 2007
All material © and ™ of Pay and Shop Limited, trading as Realex Payments.
This guide is strictly confidential and intended for customer use only.
Realex Payments, The Forum, 29/31 Glasthule Road, Glasthule, Co. Dublin, Ireland
telephone: +353 (0)1 280 8559 - email: info@realexpayments.com - web: www.realexpayments.com
Introduction to Realex Payments
Thank you for your interest in our service. Realex Payments build and manage payment
exchanges for businesses, merchants and banks. We provide a range of real time services in
the area of card authorisation, fraud scoring, electronic funds transfer, foreign exchange,
reporting and reconciliation tools and payer authentication.
Certified and approved by many leading financial institutions, these services are designed to
eliminate overhead for banks and merchants selling in call/contact centres or via the internet.
We may be contacted by any of the following methods:
Address The Forum

29/31 Glasthule Road
Glasthule
Co Dublin Ireland
Telephone + 353 (0)1 280 8559
Fax + 353 (0)1 280 8538
Sales email sales@realexpayments.com
Support email support@realexpayments.com
Web Site www.realexpayments.com
Please note that this document is regarded as confidential and it is for customer use only. It
has been supplied under the conditions of your payment-processing contract.
Pay and Shop Limited, trading as Realex Payments has its registered office at 29/31 Glasthule
Road, Glasthule, Co. Dublin, Ireland and is registered in Ireland, company number 324929.
1 Realex Services
Realex Payments offer a range of payment and financial services to banks, internet and call
centre merchants. Our core business is the creation and running of payment exchanges that
link banks with their customers via the internet.
We provide the following:
♦ Real time credit and debit card authorisation services.

♦ Real time fraud scoring and pattern checking services.
♦ A direct debit and recurring credit card payment service.
♦ A link to third party providers who offer dynamic currency conversion services.
♦ Payer authentication services for merchants and banks.
♦ Multi channel reporting and management tools.
♦ White labelled and customised payment exchanges.
Should you be interested in learning more about any of these services we would be delighted
to hear from you.
2 Introduction
Although the sample code available provides a simple interface to the system, more complex
implementations will require some knowledge of how the system works. Again, the Realauth
XML definitions guide should be consulted for full details on the messages required.
The following indicators are used to show whether or not an element is required or optional.
R Required for this request type

O Optional
R Required depending on another optional field
For each element of the XML the length and format of the field is given in the following
fashion:
A Alpha/Character (A-Za-z “ ” - _)
N Numeric (0-9)
S Special Characters (@ / ~ etc..)
V Variable length
For example:
AN50V – Alpha Numeric field, up to 50 characters in length
N3 – Numeric field, exactly 3 characters in length
3 Requests
There are seven realauth request types. The main request type is the auth request type,
which is used to obtain an authorisation for a particular debit or credit card. The remaining
request types are manual, offline, rebate, void, realscore and settle. These request types are
explained below.
3.1 Auth Request Type
Below is a sample of an auth request followed by a line-by-line analysis. The auth request is
the primary request used with realauth.
<request timestamp="20010427124523" type="auth">

<merchantid>merchantid</merchantid>
<account>subaccount</account>
<orderid>orderid</orderid>
<amount currency="GBP">2000</amount>
<card>
<number>490303400005718902</number>
<expdate>0403</expdate>
<chname>John Doe</chname>
<type>SWITCH</type>
<issueno>1</issueno>
<cvn>
<number>453</number>
<presind>1</presind>
</cvn>
</card>
<autosettle flag="1" />
<comments>
<comment id="1">a comment</comment>
<comment id="2">another comment</comment>
</comments>
<tssinfo>
<custnum>customer number</custnum>
<prodid>product id</prodid>
<varref>variable reference</varref>
<custipaddress>www.xxx.yyy.zzz</custipaddress>
<address type="billing">
<code>zip/postal code</code>
<country>country</country>
</address>
<address type="shipping">
</address>
</tssinfo>
<sha1hash>4dc4f20acc….30314758a1bc</sha1hash>
<md5hash>67dcc….787307</md5hash>
</request>
SHA1 Initial Hash String

timestamp.merchantid.orderid.amount.currency.cardnumber
Example for this request:
20010427124523.merchantid.orderid.2000.GBP.490303400005718902
Top-level element. Must have
timestamp and type attributes. If the
N14/
<request timestamp="20010427124523" type="auth"> R timestamp is more than a day (86400
AN50V
seconds) away from the server time
then the request is rejected.
This is your realex payments assigned
<merchantid>merchantid</merchantid> R AN50V
merchant id
This is the realex payments sub-
account to use. If you omit this
<account>subaccount</account> O AN30V
element then we will use your default
account
The unique order id of this transaction.
<orderid>orderid</orderid> R AN50V Must be unique across all of your sub-
accounts.
The currency and amount of the
transaction. Appendix B of the realauth
A3/ developer’s guide specifies the
<amount currency="GBP">2000</amount> R
N10V currency codes. The amount should be
in the smallest unit of the required
currency (i.e. 2000 = £20, $20 or €20)
There must be a card element in auth
<card> R
requests
<number>490303400005718902</number> R N19V The card number.
The card expiry date. The format is
<expdate>0403</expdate> R N4
mmyy
<chname>John Doe</chname> R AN100V The card holder’s name.
The card type. The legal values are:
<type>SWITCH</type> R A20V VISA, MC, AMEX, LASER, SWITCH,
DINERS
The issue number of the card in the
<issueno>1</issueno> Ro N2V case of a Switch card. Only required if
the card type is SWITCH
The card verification details element. If
<cvn> O you use this then the next two
elements are required.
The Card Verification Number. This is
the 3 digit number on the reverse of
<number>453</number> Ro N4V
the card. (the CVC for VISA and the
CVV2 for MasterCard)
This is the presence indicator. It can
take 4 values:
1: cvn present
<presind>1</presind> Ro N1
2: cvn illegible
3: cvn not on card
4: cvn not requested
</cvn>
</card>
The auto-settle indicator. If “1” then
the transaction will be sent to the bank
for settlement tonight. If set to “0”
<autosettle flag="1" /> R N1
then the transaction will remain in the
realex payment’s database for 28 days
or until manually settled.
You can associate up to 2 comments
<comments> O with any transaction for your own
purposes.
<comment id="1">a comment</comment> O AN255V Free-text comment
<comment id="2">another comment</comment> O AN255V Free-text comment
</comments>
As part of the realex payment’s service
we offer a realscore. This is a real time
transaction screening and data
<tssinfo> O
checking system to assist the merchant
with the identification of potentially
high-risk transactions.
The number you assign to the
<custnum>customer number</custnum> O ANS50V customer. This can allow checking of
previous transactions by this customer.
The product code you assign to the
<prodid>product id</prodid> O ANS50V
product.
Any reference you also would like to
assign to the customer. This can allow
<varref>variable reference</varref> O ANS50V
checking, using realscore, of previous
transactions by this customer.
<custipaddress>www.xxx.yyy.zzz</custipaddress> O AN14V The IP address of the customer
<address type="billing"> O The billing address of the customer.
The ZIP/Postal code of the billing
address. This can be checked (in
<code>zip/postal code</code> O AN30V
conjunction with the country) against a
table of high-risk area codes.
The country of the billing address. This
<country>country</country> O AN2V can be checked against a table of high-
risk countries.
</address>
<address type="shipping"> O The shipping address of the customer.
The ZIP/Postal code of the shipping
address. This can be checked (in
conjunction with the country) against a
table of high-risk area codes.
The country of the shipping address.
<country>country</country> O AN2V This can be checked against a table of
high-risk countries.
</address>
</tssinfo>
The SHA-1 hash of certain elements of
the request. The details of this are to
<sha1hash>4dc4f20acc….30314758a1bc</sha1hash> R AN40 be found in the realauth developer’s
guide. Either this or the MD5 may be
used.
The MD5 hash of certain elements of
<md5hash>67dcc….787307</md5hash> R AN32
be found in the realauth developer’s
guide.
</request>
3.2 Manual Request Type
If for any reason you are unable to get an authorisation through the realex payments
authorisation system, e.g. your internet connection is unavailable, you may get an authcode
directly from your acquiring banks authorisation centre by phone. Once your internet
connection is restored you can send a manual authorisation request (including the authcode
that you received from the authorisation centre) to realex payments.
This request is not allowed by default, and realex payments may require confirmation from
your bank to allow you to use this facility.
Below is a sample of a manual authorisation request followed by a line-by-line analysis.
<request timestamp="20010427124523" type="manual">

<authcode>auth code from alternative source</authcode>
<card>
<number>490303400005718902</number>
<type>SWITCH</type>
<cvn>
</cvn>
</card>
<comments>
</comments>
<tssinfo>
</address>
</address>
</tssinfo>
</request>

N14/ timestamp is more than a day
<request timestamp="20010427124523" type="manual"> R
AN50V (86400 seconds) away from the
server time then the request is
rejected.
This is your realex payments
assigned merchant id (not the
merchant number that the bank will
assign you)
account to use. If you omit this
<account>subaccount</account> O AN30V
element then we will use your default
account
The unique order id of this
<orderid>orderid</orderid> R AN50V transaction. Must be unique across
all of your accounts.
The authcode you received from the
<authcode>authcode</authcode> R AN10V voice authorisation centre, or
alternative source.
transaction. Appendix B of the realex
developer’s guide specifies the
A3/
<amount currency="GBP">2000</amount> R currency codes. The amount should
N10V
be in the smallest unit of the
required currency (i.e. 2000 = £20,
$20 or €20)
There must be a card element in
<card> R
auth requests
<number>490303400005718902</number> R N19V The card number.
The card expiry date. The format is
<expdate>0403</expdate> R N4
mmyy
<chname>John Doe</chname> R AN100V The card holder’s name.
The card type. The legal values are:
<type>SWITCH</type> R A20V VISA, MC, AMEX, LASER, SWITCH,
DINERS
The issue number of the card in the
<issueno>1</issueno> Ro N2V case of a Switch card. Only required
if the card type is SWITCH
The card verification details element.
<cvn> O If you use this then the next two
elements are required.
The Card Verification Number. This is
the 3 digit number on the reverse of
<number>453</number> Ro N4V
the card. (the CVC for VISA and the
CVV2 for MasterCard)
This is the presence indicator. It can
take 4 values:
1: cvn present
2: cvn illegible
<presind>1</presind> Ro N1 3: cvn not on card
4: cvn not requested
In practise this is generally a drop
down box that the cardholder can
select the appropriate value from.
</cvn>
</card>
the transaction will be sent to the
bank for settlement tonight. If set to
<autosettle flag="1" /> R N1 “0” then the transaction will sit in the
realex payment’s database until
someone manually submits it for
settlement
purposes.
</comments>
As part of the realex payment’s
service we offer a realscore. This is
a real time transaction screening and
<tssinfo> O
data checking system to assist the
merchant with the identification of
potentially high-risk transactions.
The number you assign to the
customer. This can allow checking of
<custnum>customer number</custnum> O ANS50V
previous transactions by this
customer.
The product code you assign to the
<prodid>product id</prodid> O ANS50V
product.
Any reference you also would like to
assign to the customer. This can
<varref>variable reference</varref> O ANS50V
allow checking of previous
transactions by this customer.
<address type="billing"> O The billing address of the customer.
The ZIP/Postal code of the billing
address.
The country of the billing address.
<country>country</country> O AN2V This can be checked against a table
of high-risk counties.
</address>
The shipping address of the
<address type="shipping"> O
customer.
The ZIP/Postal code of the shipping
address.
The country of the shipping address.
<country>country</country> O AN2V This can be checked against a table
of high-risk counties.
</address>
</tssinfo>
<sha1hash>4dc4f20acc….30314758a1bc</sha1hash> R AN40 The SHA-1 hash
<md5hash>67dcc….787307</md5hash> R AN32 The MD5 hash.
</request>
3.3 Offline Request Type
In some cases, you bank may reject a transaction with the error: 101 / REFERRAL B or
CONTACT AUTH CENTRE. In this case there may not be a problem with the card, but
because of the large amount being authorised or the location of the merchant they would
prefer to speak to the merchant before authorising the card. You can call your authorisation
centre and request an authcode for these transactions. You may then use the Offline
authorisation request type to complete the transaction.
The offline transaction will be linked to the original transaction for which the 101 / REFERRAL
B or CONTACT AUTH CENTRE result was received. You will need to have the original order ID
and pasref available.
Below is a sample of an offline request followed by a line-by-line analysis.
<request timestamp="20010427124312" type="offline">

<orderid>original-orderid</orderid>
<pasref>original realex payments reference</pasref>
<authcode>authcode from auth centre</authcode>
<comments>
<comment id="1">comment 1</comment>
</comments>
<sha1hash>7384ae67....ac7d7d</sha1hash>
<md5hash>34e7....a77d</md5hash>
</request>

timestamp.merchantid.orderid...
20010427124312.merchantid.orderid...

<request timestamp="20010427014523" type="offline"> R
rejected.
assigned merchant id (not the
merchant number that the bank will
assign you)
account to use. For this request type
<account>original-subaccount</account> O AN30V
you must use the same sub-account
as the original transaction.
The unique order id of the original
<orderid>original-orderid</orderid> R AN50V
transaction.
The realex payments reference of
<pasref>original-realex-pasref</pasref> R AN40V
the original transaction (this was
included in the response).
The authcode given to you by the
<authcode>authcode-from-auth-centre</authcode> R AN10V
authorisation centre.
purposes.
<comment id="1">comment 1</comment> O AN255V Free-text comment
</comments>
The SHA-1 hash of certain elements
of the request. The details of this are
<sha1hash>7384ae67....ac7d7d</sha1hash> R AN40 to be found in the epage integration
guide. Either this or the MD5 may be
used.
be found in the epage integration
<md5hash>34e7....a77d</md5hash> R AN32 guide. Either this or the SHA-1 may
be used (however we do suggest you
use the SHA-1 hash as it has been
proven to be more secure).
</request>
3.4 Rebate Request Type
It is possible to process rebates through the realauth and realcontrol interfaces. A rebate is a
refund to an existing successfully settled authorisation.
In order to ensure a valid request via realauth the following conditions must be met:
• The order id, pasref, and authcode must match the values from the original transaction.
• You may only rebate:
0 to 115% of the value of the original transaction;

using the original currency;
using the same sub-account used in the original transaction;
The order id you send in the rebate request must be the original order id. A new order id is
assigned by realex payments (specifically it will be the original transaction order id prefixed
with _rebate_).
(These conditions are not required when processing refunds via the realcontrol interface.)
For an extra layer of security we require the rebate password to be passed in the XML in the
refundhash XML element. This must be hashed using the SHA1 algorithm.
Below is a sample of a rebate request followed by a line-by-line analysis.
<request timestamp="20010427124312" type="rebate">

<account>original-subaccount</account>
<pasref>original-realex-payments-pasref</pasref>
<authcode>original-authcode</authcode>
<amount currency="EUR">3000</amount>
<refundhash>738e83....3434ddae662a</refundhash>
<comments>
</comments>
<sha1hash>748328aed83....34789ade7</sha1hash>
<md5hash>738e83....34ae662a</md5hash>
</request>

timestamp.merchantid.orderid.amount.currency.
20010427124312.merchantid.orderid.3000.EUR.
<request timestamp="20010427124312" type="rebate"> R
rejected.
assigned merchant
<account>original-account</account> O AN30V
you must use the same sub-account
as the original transaction.
transaction.
The realex payments reference of
<pasref>original-realex- pasref</pasref> R AN40V the original transaction (this was
included in the response).
The authcode of the original
<authcode>original-authcode</authcode> R AN10V transaction (this was included in the
response).
transaction. Appendix B of the
realauth developer’s guide specifies
the currency codes. The amount
A3/ should be in the smallest unit of the
<amount currency="EUR">3000</amount> R
N10V required currency (i.e. 2000 = £20,
$20, 20 euros or 2000 lire). Must be
the same currency as used in the
original transaction and may only be
up to 115% of the original value.
This is a hash of the refund password
(realex payments will give this to
<refundhash>738e83....3434ddae662a</refundhash> R AN40
you). The SHA1 algorithm must be
used to generate this hash.
the transaction will be sent to the
bank for settlement tonight. If set to
“0” then the transaction will sit in the
<autosettle flag="1" /> R N1
realex payments database until
someone manually submits it for
settlement. For rebates you will
generally set this to “1”.
<comments> O
</comments>
The SHA-1 hash of certain elements
<sha1hash>748328aed83....34789ade7</sha1hash> R AN40
of the request.
<md5hash>738e83....34ae662a</md5hash> R AN32 the request. hash as it has been
proven to be more secure).
</request>
3.5 Void Request Type
Below is a sample of a void request followed by a line-by-line analysis.
<request timestamp="20010427014523" type="void">

<account>original-subaccount</account>
<comments>
</comments>
</request>

It is possible to void an authorisation, manual, offline or rebate request, before settlement. If

the transaction has been settled or batched then it cannot be voided and you can either submit
another authorisation or rebate.

N14/
<request timestamp="20010427014523" type="void"> R timestamp is more than a day (86400
AN50V
seconds) away from the server time
then the request is rejected.
merchant id.
<account>sub-account</account> O AN30V
you must use the same sub-account as
the original transaction.
<orderid>original-orderid</orderid> R AN50V The original order id of the transaction.
The realex payments reference of the
<pasref>original-realex-pasref</pasref> R AN40V
original transaction.
The authcode of the original transaction
<authcode>original-authcode</authcode> R AN10V
(this was included in the response).
<comments> O
with any transaction.
</comments>
<sha1hash>7384ae67....ac7d7d</sha1hash> R AN40
the request.
<md5hash>34e7....a77d</md5hash> R AN32
the request.
</request>
3.6 realscore Request Type
Below is a sample of a realscore request.
<request timestamp="20010427124523" type="tss">

<card>
<number>490303400005718902</number>
<type>SWITCH</type>
<cvn>
</cvn>
</card>
<comments>
</comments>
<tssinfo>
</address>
</address>
</tssinfo>
</request>

This is exactly the same format as an auth request (only the type attribute of the request has
changed). The only difference between an auth request and a realscore request is that no
auth is performed for a realscore request. Only the realscore and the results of the individual
checks are returned.
For a line-by-line analysis please see the auth request type (section 3.1).
3.7 Settle Request Type
This only applies to transactions that were sent to realex payments with the autosettle flag off.
Transactions with the autosettle flag set to 1 will settle automatically the next day.
Below is a sample of a settle request followed by a line-by-line analysis.
<request timestamp="20010427014523" type="settle">

<comments>
</comments>
</request>

timestamp.merchantid.orderid...
The settle request is used to capture a transaction that has previously been authorised using
an auth request with the autosettle flag turned off (set to “0” or “off”). Transactions with the
autosettle flag off (known as “delayed transactions”) will sit in the database forever unless
you explicitly request that it be settled using the settle request OR void it using a void request.
NB – no funds will move from the cardholder’s account to the merchant account
unless the transaction is settled manually using the realcontrol application or
programmatically using a settle request. This only applies to delayed transactions.
Depending on the bank, delayed transactions will only be valid for a certain number of days
(ranging from 3 days to 10 days in most cases). After this time the settle request may fail and
you will need to re-authorise the transaction again.
Transactions can be settled for 0 – 115% of the originally authorised amount. Note – If you
are processing 3DSecure transactions you will need to settle for the same amount as
the initial authorisation. For more details on 3DSecure transactions, see the RealMPI
Developers Guide or e-mail support@realexpayments.com
It is possible to void a delayed authorisation request at any time before settlement.
Top-level element. Must have timestamp
and type attributes. If the timestamp is
N14/
<request timestamp="20010427014523" type="settle"> R more than a day (86400 seconds) away
AN50V
from the server time then the request is
rejected.
<merchantid>merchantid</merchantid> R AN50V merchant id (not the merchant number
that the bank will assign you)
This is the realex payments sub-account
to use. For this request type you must
<account>sub-account</account> O AN30V
use the same sub-account as the original
transaction.
transaction.
The realex payments reference of the
<pasref>original-realex-pasref</pasref> R AN40V original transaction (this was included in
the response).
The authcode of the original transaction
<authcode>original-authcode</authcode> R AN10V
(this was included in the response).
You can associate up to 2 comments with
<comments> O
any transaction for your own purposes.
</comments>
the request. The details of this are to be
<sha1hash>7384ae67....ac7d7d</sha1hash> R AN40
found in the realauth developer’s guide.
Either this or the MD5 may be used.
The MD5 hash of certain elements of the
request. The details of this are to be
found in realauth developer’s guide.
<md5hash>34e7....a77d</md5hash> R AN32 Either this or the SHA-1 may be used
(however we do suggest you use the
SHA-1 hash as it has been proven to be
more secure).
</request>
4 Responses
A response will be returned for every request sent to Realex. There are two different response
classes that can be returned: Full responses and basic responses. The details of the response
messages are given below.
Depending on how far the request has progressed before the response is generated you will or
will not receive a hash in the response. For example – if you use the wrong merchant id, there
is no way for us to retrieve your shared secret and create the hash.
You will only receive a full response if the request is valid (i.e. the xml is properly formatted,
the data is within legal limits, the information in the data is legal etc…). Therefore your
application must cater for both full and basic responses.
You can find a full list of result codes in the Appendix of the realauth developer’s guide.
4.1 Result codes that will return full responses
00 Successful Transaction
1xx Bank errors
2xx EPoS errors
4.2 Result codes that will only return code and message
3xx Realex payments errors

5xx Developer/Data errors
4.3 Response Format
The full version of the response is shown below, followed by the short version and a line-by-
line description.
Full response:
<response timestamp="20010427043422">
<orderid>orderid-from-request</orderid>
<authcode>authcode-received</authcode>
<result>00</result>
<message>message-returned-from-system</message>
<pasref>realex-pasref</pasref>
<cvnresult>M</cvnresult>
<batchid>batchid-for-this-transaction</batchid>
<cardissuer>
<bank>Issuing Bank Name</bank>
<country>Issuing Bank Country</country>
<countrycode>Issuing Bank Country Code</countrycode>
<region>Issuing Bank Region</region>
</cardissuer>
<tss>
<result>89</result>
<check id="1000">9</check>
<check id="1001">9</check>
…
</tss>
</response>

timestamp.merchantid.orderid.result.message.pasref.authcode
20010427043422.merchantid.orderid-from-request.00.message-returned.realex-pasref.authcode-received
Basic response:
<response timestamp="20010427043422">
<result>508</result>
<message>message returned from system</message>
</response>
Top-level element. Will have timestamp
<response timestamp="20010427043422"> R N14
attribute.
This is the realex payments assigned
<merchantid>merchant id used</merchantid> R AN50V
merchant id used.
<account>account used</account> R AN30V This is the realex payments account used.
The order id of the request. Used when
<orderid>order id used</orderid> R AN50V referencing this transaction in refund and
void requests.
If successful there will be an authcode
returned from the bank. Used when
<authcode>authcode received</authcode> R AN10V
referencing this transaction in refund and
void requests.
The authcode of the original transaction (this
<result>00</result> R N3V
was included in the response).
The text of the response. Will contain the
<message>message returned from system</message> R AN100V authcode if successful or the error message if
not.
The realex payments reference for the
<pasref> realex payments reference</pasref> R AN40V transaction. Used when referencing this
transaction in refund and void requests.
The result of the Card Verification check:
M: CVV Matched
N: CVV Not Matched
<cvnresult>M</cvnresult> R A1
I: CVV Not checked due to circumstances
U: CVV Not checked – issuer not certified
P: CVV Not Processed
The batch id of the transaction. Returned in
the case of auth and refund requests. This
<batchid>batch id</batchid> R AN10V
can be used to assist with the reconciliation
of your batches.
The Details of the cardholder’s bank (if
<cardissuer> R
available)
<bank>Issuing Bank Name</bank> R AN100V The Bank Name (e.g. First Data Bank)
The Bank Country in English (e.g. UNITED
<country>Issuing Bank Country</country> R AN40V
STATES)
The country code of the issuing bank (e.g.
<countrycode>Issuing Bank Co Code</countrycode> R AN2
US)
The region the card was issued (e.g. US) Can
be MEA (Middle East/Asia), LAT (Latin
<region>Issuing Bank Region</region> R AN20V
America), US (United States), EUR (Europe),
CAN (Canada), A/P (Asia/Pacific)
</cardissuer> R
<tss> O The results of realscore
The weighted total score of realscore. You
<result>67</result> R N3V may adjust the weights in the realcontrol
application.
The result of realscore check number xxxx.
N4/
<check id="xxxx">9</check> R You can choose which checks to return using
N1
the realcontrol application.
</tss>
The SHA-1 hash of certain elements of the
<sha1hash>7384ae67....ac7d7d</sha1hash> R AN40 response. The details of this are to be found
in the realauth developer’s guide.
The MD5 hash of certain elements of the
<md5hash>34e7....a77d</md5hash> R AN32 response. The details of this are to be found
in the realauth developer’s guide.
</response>
5 Contact details.
Should you have any queries please contact Realex Payments by any of the means below:
Realex Payments
The Forum
29/31 Glasthule Road
Glasthule, Co, Dublin, Ireland.
email – support@realexpayments.com
Phone + 353 (0) 1 280 8559
Fax + 353 (0) 1 280 8538
www.realexpayments.com
Appendix A – Version Control
Version Date Amendments Completed By

1.2.1 16/6/06 Included possible cvnresult codes Chris Dare
1.2.2 11/09/06 Updated CVN results Darren G
1.3 19/06/07 Added SHA1 details. Brendan H.

Xmldefs

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Xmldefs

Diunggah oleh

Hak Cipta:

Format Tersedia

Realauth XML Definitions Guide

Page 2 - Version 1.2.2 Printed on: 21 Jun 2007

We may be contacted by any of the following methods:

Address The Forum

Page 3 - Version 1.2.2 Printed on: 21 Jun 2007

We provide the following:

♦ Real time credit and debit card authorisation services.

R Required for this request type

Page 4 - Version 1.2.2 Printed on: 21 Jun 2007

3.1 Auth Request Type

<request timestamp="20010427124523" type="auth">

SHA1 Initial Hash String

Page 5 - Version 1.2.2 Printed on: 21 Jun 2007

Page 6 - Version 1.2.2 Printed on: 21 Jun 2007

Page 7 - Version 1.2.2 Printed on: 21 Jun 2007

Below is a sample of a manual authorisation request followed by a line-by-line analysis.

<request timestamp="20010427124523" type="manual">

Page 8 - Version 1.2.2 Printed on: 21 Jun 2007

Top-level element. Must have

Page 9 - Version 1.2.2 Printed on: 21 Jun 2007

Page 10 - Version 1.2.2 Printed on: 21 Jun 2007

Below is a sample of an offline request followed by a line-by-line analysis.

<request timestamp="20010427124312" type="offline">

SHA1 Initial Hash String

Top-level element. Must have

Page 11 - Version 1.2.2 Printed on: 21 Jun 2007

Page 12 - Version 1.2.2 Printed on: 21 Jun 2007

0 to 115% of the value of the original transaction;

Below is a sample of a rebate request followed by a line-by-line analysis.

<request timestamp="20010427124312" type="rebate">

SHA1 Initial Hash String

Page 13 - Version 1.2.2 Printed on: 21 Jun 2007

Page 14 - Version 1.2.2 Printed on: 21 Jun 2007

Below is a sample of a void request followed by a line-by-line analysis.

<request timestamp="20010427014523" type="void">

SHA1 Initial Hash String

It is possible to void an authorisation, manual, offline or rebate request, before settlement. If

Top-level element. Must have

Page 15 - Version 1.2.2 Printed on: 21 Jun 2007

Below is a sample of a realscore request.

<request timestamp="20010427124523" type="tss">

SHA1 Initial Hash String

Page 16 - Version 1.2.2 Printed on: 21 Jun 2007

Below is a sample of a settle request followed by a line-by-line analysis.

<request timestamp="20010427014523" type="settle">

SHA1 Initial Hash String

It is possible to void a delayed authorisation request at any time before settlement.

Page 17 - Version 1.2.2 Printed on: 21 Jun 2007

Page 18 - Version 1.2.2 Printed on: 21 Jun 2007

4.1 Result codes that will return full responses

3xx Realex payments errors

Page 19 - Version 1.2.2 Printed on: 21 Jun 2007

SHA1 Initial Hash String

Page 20 - Version 1.2.2 Printed on: 21 Jun 2007

Page 21 - Version 1.2.2 Printed on: 21 Jun 2007

Appendix A – Version Control

Version Date Amendments Completed By

Page 22 - Version 1.2.2 Printed on: 21 Jun 2007

Anda mungkin juga menyukai