Windcave iPP350 User manual

Version 2.3
Host Initiated Transactions

Page 2 of 27
Document Revision Information
Version Comments
0.1 Initial version.
0.2 Added Payline information.
0.3 Update to Document Formatting.
1.0 Release Version.
1.1 Signature support and Cancel transaction functionality.
1.2 Update to production endpoint address & transaction ow.
1.3 Removed DCC & Locate functions for now.
1.4 Added additional ReCo information & added Sandbox.
1.5 Added Paymark section updated images & xed typos. Updated Void and Refunds. Included
new conguration information.
1.6 Formatting changes.
1.7 Included cash out functionality.
1.8 Update to refund section and buttons.
1.9 Included multi-user testing.
2.0 Included additional ReCos and updated transaction completion response information.
2.1 Included Receipt transaction request.
2.2 Included Fail-Proof Result Notication functionality.
2.3 Rebranded Whole Document. Updated IWL250 documentation to Move5000 documentation -
Lorenzo Fernandez

Page 3 of 27
Copyright
© Copyright 2019, Windcave Ltd
33 Wilkinson Road,
PO Box 8400
Auckland 1060
New Zealand
www.windcave.com
All rights are reserved. No part of this work may be reproduced or copied in any form or by any means, electronic
or mechanical, including photocopying, without the express written permission of Windcave Limited.
Proprietary Notice
The information described in this document is proprietary and condential to Windcave. Any unauthorised use
of this material is expressly prohibited except as authorised by Windcave Limited in writing.

Page 4 of 27
Contents
1Introduction............................................................................................................................................................... 5
2Operation................................................................................................................................................................... 6
2.1 Endpoints & Firewall Considerations....................................................................................................................... 6
3Congurations .......................................................................................................................................................... 7
3.1 Direct external connection ....................................................................................................................................... 7
3.1.1 Direct external connection iPP350 .......................................................................................................................... 7
3.1.2 Direct external connection Move5000..................................................................................................................... 7
3.2 Connection to PC...................................................................................................................................................... 8
3.2.1 Connection to PC iPP350......................................................................................................................................... 8
3.2.2 Connection to PC Move5000 ................................................................................................................................... 8
3.3 IPP350 with MTM200............................................................................................................................................... 9
3.4 3G connection with Move5000 ................................................................................................................................ 9
3.5 Paymark key set up (NZ Only)................................................................................................................................ 10
3.6 Terminal conguration ........................................................................................................................................... 10
3.6.1 Initialisation............................................................................................................................................................. 10
3.6.2 Logon ...................................................................................................................................................................... 10
4Transaction Flow .................................................................................................................................................... 11
5Message Specication ........................................................................................................................................... 12
5.1 Transaction............................................................................................................................................................. 12
5.2 Status ...................................................................................................................................................................... 14
5.3 Buttons.................................................................................................................................................................... 17
5.4 Refunds ................................................................................................................................................................... 18
5.5 Receipt .................................................................................................................................................................... 19
6 Fail-Proof Result Notication (FPRN)………………………………………..……..…………………….……………………………………………………20
6.1 Fail-Proof Result Notication Transaction Flow…………………………………………………...……………………………………………………21
7Response Codes..................................................................................................................................................... 22
8TxnStatusId & StatusId........................................................................................................................................... 23
9 Parameters.............................................................................................................................................................. 24
10 Real-time Transaction Monitoring.......................................................................................................................... 26
11 Contact Windcave................................................................................................................................................... 27

Page 5 of 27
1 Introduction
The Windcave Host Initiated Transaction (HIT) solution is a web facing HTTPS service that permits control of a pay-
ment transaction on a Windcave terminal.
There is no requirement of a direct physical connection between the Point of Sale (POS) application and the
Windcave terminal. All required software is on the Windcave Terminal and Host. All messages are sent online via the
internet to create an end-to-end cloud-based payment solution.
The terminal can be connected online to a modem or router directly. However if required the HIT enabled terminal
can be connected to a POS’s PC as well to share the internet connection from the PC, in that case the POS’s PC
needs to have an SCR Controller software installed. For further details please refer to section 3 - Congurations.
The Windcave HIT sandbox is accessible online https://demo.windcave.com/SandboxPxHIT.aspx

Page 6 of 27
2 Operation
The POS initiates a transaction request to Windcave by sending an HTTPS POST request as an XML message to the
appropriate URL. See below section 2.1 (Endpoints & Firewall Considerations) for a list of URLs.
Windcave responds to the request, either immediately or after a congurable timeout period of a few seconds; after
receiving a response, the POS will continue to make Status requests until the Status response indicates that the
transaction is Complete (Complete value is returned as “1”) in Result.
Status responses from Windcave may contain instructions for the POS to permit information to be displayed for the
merchant (DL1, DL2) and enablement of buttons that may be used by the POS to interrupt the transaction or provide
feedback for example signature capture.
Note: For any new integrations, the POS must handle the entry of new users. POS applications are typically used by
many different customers.
As each customer has one or more HIT API users, a key part of POS development is ensuring that new user HIT
API credentials can be easily added into the POS and that the development credentials are not hard coded in any
way. Please ensure the API credentials conguration within the POS are also password protected or has some lev-
el of authorised access challenge.
2.1 Endpoints & Firewall Considerations
The POS can communicate with the Payment Host using HTTPS on the addresses below. Please ensure that your
network can accommodate this access.
Production: https://sec.windcave.com/pxmi3/pos.aspx
Test: https://uat.windcave.com/pxmi3/pos.aspx
The Windcave HIT terminal communicates with the Windcave Host using TCP on the addresses below. Please en-
sure that your network can accommodate this access.
Production: scr.windcave.com port 65
Test: uat.windcave.com port 65

Page 7 of 27
3 Congurations
3.1 Direct External Connection
Windcave HIT terminals can be congured to connect directly to an external Internet connection; this allows mer-
chants to remove all physical connection between their POS and the payment device; this option is available for both
the iPP350 and the Move5000.
No Windcave software is required on the PC running the POS. However only the Windcave key scheme is supported.
3.1.1 Direct External Connection iPP350
The iPP350 terminal is connected to an external network using three separate cables:
The customer must have a receipt printer and all receipt printing is controlled directly by the POS.
3.1.2 Direct External Connection Move5000
The Move5000 terminal is connected for online connectivity to an external network (via a router or modem) using a

Page 8 of 27
3.2 CONNECTION TO PC
Both the iPP350 and the iWL250 can be connected directly to the merchant’s POS. In order to run the HIT device, the
merchant must download the SCRController software from the Windcavewebsite.
Windcave and Paymark (NZ only) terminal key schemes are available.
3.2.1 Connection to PC iPP350
The iPP350 is connected directly to the POS using one USB-A cable:
The customer must have a receipt printer. The HIT response will contain the receipt content which is required to be
printed by the POS’s own receipt printer.
3.2.2 Connection to PC Move5000
The iWL25C terminal is connected directly to the POS using one USB-A cable. The device must also have power to
the base.
All printing is handled directly by the terminal’s on-board thermal printer.

Page 9 of 27
3.3 IPP350 with MTM300
The iPP350 can be connected directly to the MTM300. The MTM300 includes a thermal printer and allows both Pay-
mark and Windcave key schemes to be used. The MTM300/iPP350 connection requires two separate cables:
All printing is handled by the MTM300’s on-board thermal printer.
3.4 3G Connection with Move5000
The Move5000 accepts SIM cards which allows it to communicate using 3G. No cable connection is required other
than the standard power cable to the base.
Only Windcave keys can be used with this set up.
All printing is handled by the on-board thermal printer

Page 10 of 27
3.5 Paymark key set up (NZ Only)
Terminals using the Paymark key scheme must have their keys remotely injected before transacting. Please contact
our support team for assistance.
3.6 Terminal conguration
The Windcave terminal should come with precongured network settings. If there are any connectivity issues that
cannot be resolved, please contact Windcave Support staff.
3.6.1 Initialisation
Once powered up, the device will go through an automatic boot-up and online logon process. Once completed &
ready, PINpad will idle and display “EFTPOS” on the screen.
3.6.2 Logon
In order to prepare the terminal for processing transactions, the Logon message is used. A Logon uses the assigned
merchant number and terminal ID to login to the banking switch. This is recommended but optional as the terminal
will automatically log itself with the Windcave Host 10 seconds after connecting to the network. However if logon is
required please do the following manual logon process. Press the “Menu” button on the PINpad, and select “LOGON”.

Page 11 of 27
4 Transaction Flow

Page 12 of 27
5 Message Specication
This section describes communication aspects of the HIT XML messages specication.
5.1 Transaction
To initiate a transaction the following SCR XML message specied needs to be posted to the HIT POS endpoint.
5.1.1 Transaction Request – Input Parameters
Transaction request elds or properties to initiate a card present transaction with HIT
Property\[Attribute] Required Description
[user] Yes
HIT Username provided by Windcave Alphanumeric, from 1 to 32 charac-
ters in length. Please ensure this is securely congurable via the POS con-
g.
[key] Yes HIT Key provided by Windcave. Alphanumeric, from 1 to 64 characters in
length. Please ensure this is securely congurable via the POS cong.
Station Yes Station Id unique to the terminal. Alphanumeric, from 1 to 32 characters.
Please ensure this is securely congurable via the POS cong.
Amount Yes Amount of transaction in D.CC format. Where D is dollar and C is cent val-
ue. Numeric and decimal point, from 1 to 13 digits.
AmountCash No Amount for cash out. Numeric and decimal point, from 1 to 13 digits.
Cur Yes Currency of the transaction. Alphanumeric, 3 characters only allowed.
TxnType Yes
Transaction Type. Valid values: Purchase, Auth, Refund or Status.
Please note for requesting the Complete transaction after an Auth transac-
tion from the terminal please use our PxPost or WebService API.
TxnRef Yes Set by POS to uniquely identify transactions. Alphanumeric, from 1 to 40
characters.
DeviceId Yes HIT POS identier provided by POS. For example, a POS Lane Identier etc.
Alphanumeric, from 1 to 32 characters.
PosName Yes PosName – agreed between POS Vendor and Windcave. Alphanumeric,
from 1 to 32 characters.
PosVersion No Version of POS. Supplied by POS to assist transaction recording and diag-
nosis. Alphanumeric, from 1 to 32 characters.
VendorId Yes The developer of the POS Application. This is agreed between Windcave
and vendor. Alphanumeric from 1 to 32 characters in length.
MRef No Merchant text eld. Alphanumeric, max 64 characters. Recommend to use,
useful for reporting purposes.
UrlSuccess No Set the URL to receive a HTTP GET notication on approved card present
payment
UrlFail No Set the URL to receive a HTTP GET notication on declined card present
payment
Example Transaction Request:
<Scr action="doScrHIT" user="xxx" key="yyy">
<Amount>1.05</Amount>
<Cur>NZD</Cur>
<TxnType>Purchase</TxnType>
<Station>1234567890</Station>
<TxnRef>123</TxnRef>
<DeviceId>Device 1</DeviceId>
<PosName>POS 1</PosName>
<PosVersion>Pos V1</PosVersion>
<VendorId>PXVendor</VendorId>
<MRef>My Reference</MRef>
</Scr>

Page 13 of 27
5.1.2 Initial Transaction Status Response – Output Parameters
Example Status Response:
<Scr>
<TxnType>Status</TxnType>
<StatusId>3</StatusId>
<TxnStatusId>2</TxnStatusId>
<Complete>0</Complete>
<ReCo/>
<Tmo>20</Tmo>
<TxnRef>123</TxnRef>
<DL1>PRESENT/INSERT</DL1>
<DL2> SWIPE CARD</DL2>
<B1 en="0"/>
<B2 en="1">CANCEL</B2>
</Scr>
Property\[Attribute] Description
TxnType Transaction Type. Normally the HIT transaction response’s TxnType value is
as Status.
StatusId Status of the current request.
TxnStatusId Status ID related to current transaction.
Complete If transaction is completed this eld will be set to 1.
ReCo Response Code indicating outcome. See 3 IntroductionResponse for a details
description of ReCo values.
Tmo Http Timeout in operation for the request.
TxnRef TxnRef value for the original request and transaction.
DL1 Display Line 1. If not empty, the merchant display should display this on the
uppermost lines.
DL2 Display Line 2. If not empty, the merchant display should display this on the
lowermost line.
B1 Button1. If not blank, contains label for a button that permits the POS to inter-
act with the transaction. The “en” attribute will be “1” if the button should be
active and displayed.
B2 Button2. If not blank, contains label for a button that permits the POS to inter-
act with the transaction. The “en” attribute will be “1” if the button should be
active and displayed.

Page 14 of 27
5.2 Status
5.2.1 Status Request
Request a Status for an active or historical transaction. Merchant POS should request this message shortly after the
transaction is initiated as per section 5.1 (Transaction). The TxnRef must match the transaction the POS wants to do
status check on.
5.2.2 Status Response
5.2.2.1 During Processing
The POS interface should always show any DL1 and/or DL2 text from the Status response to match the terminal
screen prompt text. Note in below example the DL1 display message is set to Processing.
5.2.2.2 Signature Stage
A receipt message will be available to print as well as prompts and mandatory button options YES’ and ‘NO’.
The POS should display the button options to the POS operator and a print button to print the physical merchant
copy of the receipt for the customer to sign on. The POS system is required to accept or decline a signature transac-
tions with the Yes or No button—please follow the messages for button request in section 5.3 (Buttons).
Example Status:
<Scr action="doScrHIT" user="xxx" key="yyy">
<Station>1234567890</Station>
<TxnType>Status</TxnType>
<TxnRef>123</TxnRef>
</Scr>
Example Status Response:
<Scr>
<TxnType>Status</TxnType>
<StatusId>4</StatusId>
<TxnStatusId>5</TxnStatusId>
<Complete>0</Complete>
<ReCo/>
<Tmo>20</Tmo>
<TxnRef>123</TxnRef>
<DL1>PROCESSING</DL1>
<DL2/>
<B1 en="0"/>
<B2 en="0"/>
</Scr>
Example Status Response (Signature prompted):
<Scr>
<TxnType>Status</TxnType>
<TxnRef>123</TxnRef>
<StatusId>4</StatusId>
<TxnStatusId>7</TxnStatusId>
<Complete>0</Complete>
<RcptW>30</RcptW>
<Rcpt> *-----------EFTPOS-----------*27 Mar 18 13:35 CREDITSWIPE VISA CARD
476173******0010AUTHORISATION 025211REFERENCE 029017PURCHASE NZD1.08TOTAL
NZD1.08 APPROVED PLEASE SIGN BELOW *----------------------------* MERCHANT COPY PLEASE RETAIN FOR YOUR REC-
ORDS</Rcpt>
<ReCo></ReCo>
<Tmo>20</Tmo>
<TxnRef>123</TxnRef>
<DL1>SIGNATURE OK?</DL1>
<DL2>YES/NO</DL2>
<B1 en="1">YES</B1>
<B2 en="1">NO</B2>
</Scr>

Page 15 of 27
Please Note: It is important that the POS integration continues to request a status check until after the
POS user appropriately handles the prompt on the POS and/or terminal and the nal response contains
the Complete tag value as 1. The HIT interface allows only one transaction to be fully completed at a time.
A pending transaction completion will result in an “Existing Txn In Progress” error. This should be handled
by sending the Status request for the TxnRef of the transaction until it reaches the Complete stage.
5.2.2.3 Final Status Response on completion of Transaction
On completion of a transaction the Complete XML element will be set to 1. The result of the transaction will be popu-
lated inside the Result XML element. Below property elements are contained in the transaction response and Result
XML element.
Property Description
TxnType Transaction Type. Normally the HIT transaction response’s TxnType value is as Status.
TxnRef TxnRef value for the original request and transaction.
StatusId Status of the current request Refer to the section TxnStatusId and StatusId for more infor-
mation.
TxnStatusId Status ID related to current transaction.
Complete If transaction is completed this eld will be set to 1.
RcptW Receipt Width species the maximum character limit per receipt content’s line. A terminal’s
account is setup with a default receipt width character length. The xed character limit can
be used to center justify the receipt content per line to get the standard receipt format.
Rcpt Actual EFTPOS receipt content that should be physically printed in case the POS handles
the EFTPOS receipt printing. All receipt content should be printed to ensure nancial data
integrity.
Result Encloses the nal transaction results with specic transaction data elds.
AC AuthCode. Up to 6 character authorisation code.
AP Approved ag. “1” indicated approved (funds transfer or reserve); “0” indicated declined or
not approved.
CN Masked Card Number.
Complete 1 indicates transaction session is completed. The POS should stop sending status requests
CT Card Name e.g. Visa.
DS Expected Settlement Date of Transaction. Format is yyyymmddhhmmss.
DS_TZ TimeZone applied to the DS value.
DT Date of Transaction. Returned in Timezone Format is yyyymmddhhmmss.
DT_TZ TimeZone applied to DT value.
PIX EMV specic data.
RID EMV specic data .
RRN Retrieval reference Number
ST STAN. The System Trace Audit Number which identies the transaction number processed
through the merchant account.
TR DpsTxnRef. Unique global transaction identier generated by Windcave and returned for
every transaction. This value can be provided to support teams to identify transactions.
DBID DpsBillingId is a card token generated by Windcave. Token used to rebill the card for sub-
scription or recurring based payments. Rebilling requests are sent via the PxPost or Web-
service API.
RC Response Code. See section 6 Response Codes
RT Response Text. See section 6 Response Codes.
RTT Round Trip Time in Milliseconds –provides an indication of network health (between
Windcave and Windcave Terminal).
AmtA Amount value of the transaction in cents.

Page 16 of 27
Example Final Status Response (Completed):
<Scr>
<TxnType>Status</TxnType>
<TxnRef>123</TxnRef>
<StatusId>6</StatusId>
<TxnStatusId>8</TxnStatusId>
<Complete>1</Complete>
<RcptW>30</RcptW>
<Rcpt> *-----------EFTPOS-----------*27 Mar 18 13:13 CHEQUESWIPE VISA CARD
411111******1111AUTHORISATION 000289REFERENCE 029013PURCHASE NZD1.00TOTAL
NZD1.00 APPROVED PIN VERIFIED *-----------
-----------------* CUSTOMER COPY PLEASE RETAIN FOR YOUR RECORDS</Rcpt>
<Result>
<AC>000289</AC>
<AP>1</AP>
<CN>411111******1111</CN>
<CT>Visa</CT>
<CH>VISA TEST CARD/</CH>
<DT>20180327131306</DT>
<DT_TZ>NZT</DT_TZ>
<DS>20180327180000</DS>
<DS_TZ>NZT</DS_TZ>
<PIX></PIX>
<RID></RID>
<RRN></RRN>
<ST>788359</ST>
<TR>0000000100e1a6f9</TR>
<DBID>0000010001128730</DBID>
<RC>00</RC>
<RT></RT>
<RTT>4050</RTT>
<AmtA>100</AmtA>
</Result>
<ReCo></ReCo>
<Tmo>20</Tmo>
<TxnRef></TxnRef>
<DL1>APPROVED</DL1>
<DL2></DL2>
<B1 en="0"></B1>
<B2 en="0"></B2>
</Scr>

Page 17 of 27
5.3 Buttons
POS is required to display appropriate buttons if B1 or B2 eld in the XML response(s) is not blank. Once any button
is clicked, the POS should then post appropriate button request to SCR endpoint.
5.3.1 Button Request XML
5.3.2 Button Response XML Example
Property Description
Station Station Name of the Windcave terminal being selected by the POS.
TxnType For Button Request, the value should be UI for User Interface.
UiType Bn
Name B1 or B2. Depending on the button pressed.
Val Value to be sent with the request for button press - CANCEL, YES, NO.
TxnRef Transaction reference assigned by POS. This should be different for each transaction.
Example Button:
<Scr action="doScrHIT" user="xxx" key="yyy">
<Station>1234567890</Station>
<TxnType>UI</TxnType>
<UiType>Bn</UiType>
<Name>B1</Name>
<Val>YES</Val>
<TxnRef>12345678</TxnRef>
</Scr>
Example Button Response:
<Scr>
<TxnType>UI</TxnType>
<TxnRef>12345678</TxnRef>
<Success>1</Success>
<RC></RC>
</Scr>

Page 18 of 27
5.4 Refunds
5.4.1 Matched refunds initiated via HIT request
To initiate a refund directly from the POS, the DpsTxnRef of the initial transaction must be included. The unique TxnRef
is used separately as a reference to the refund and must be unique.
5.4.2 Unmatched refunds with refund card
To initiate a refund directly from the POS and authorise with a merchant refund card, the following example XML should
be modied and sent. The DpsTxnRef tag does not need to be included, instead for authorization the terminal will
prompt for the merchant’s refund card to be swiped and PIN entered before the customer presents their card for the
refund. The merchant refund card is setup by Windcave. For extra security, it is expected the POS requires own authori-
zation before requesting unmatched refund via the POS.
5.4.3 Matched refunds via ecommerce solution
The PxPost or Web Service eCommerce API can be used to process refunds with the matched DpsTxnRef of the given
HIT transaction. For more information on PxPost and Web Service, please visit our website
https://www.windcave.com/developer-e-commerce-merchant-hosted-transaction-processing
When using PxPost or Web Service to handle refunds, the HIT user and the eCommerce API user must be associated
with the same Windcave Group; for additional information please contact our Support team.
Example Unmatched Refund:
<Scr action="doScrHIT" user="xxx" key="yyy">
<Amount>76.00</Amount>
<Cur>NZD</Cur>
<TxnType>Refund</TxnType>
<Station>1234567890</Station>
<TxnRef>987</TxnRef>
<DeviceId>1234567890</DeviceId>
<PosName>POS 1</PosName>
<PosVersion>Pos V1</PosVersion>
<VendorId>DPSVendor</VendorId>
<MRef>My Reference</MRef>
</Scr>
Example Matched Refund:
<Scr action="doScrHIT" user="xxx" key="yyy">
<Amount>76.00</Amount>
<Cur>NZD</Cur>
<TxnType>Refund</TxnType>
<Station>1234567890</Station>
<TxnRef>987</TxnRef>
<DpsTxnRef>0000005400911209</DpsTxnRef>
<DeviceId>1234567890</DeviceId>
<PosName>POS 1</PosName>
<PosVersion>Pos V1</PosVersion>
<VendorId>DPSVendor</VendorId>
<MRef>My Reference</MRef>
</Scr>

Page 19 of 27
5.5 Receipt
In case the POS requires to request the last EFTPOS receipt content to print, the POS can send a request to receive
the last transaction’s receipt content with the most recent or last transaction’s TxnRef. This can be requested to re-
print the receipt when a printer and it’s paper roll is available. Following are the request and response details specic
to get the last receipt.
5.5.1 Receipt Request XML
Property Required Description
Station Yes Station Name of the Windcave terminal being selected by the POS.
TxnType Yes For Receipt Request, the value should be Receipt.
TxnRef Yes The most recently processed transaction’s transaction reference.
DuplicateFlag No An optional tag. If value 1: Includes a DUPLICATE RECEIPT text string on
the receipt content. Otherwise 0 will not include the duplicate text string.
ReceiptType Yes A ag indicating the receipt content type to receive. Valid Values:
1 = Merchant Copy of receipt with a signature placeholder (only for signa-
ture transaction)
2 = Customer Copy of receipt
3 = Merchant Copy of receipt
Example Receipt Request:
<Scr action="doScrHIT" user="xxx" key="yyy">
<Station>4012345678</Station>
<TxnType>Receipt</TxnType>
<TxnRef>12345</TxnRef>
<DuplicateFlag>0</DuplicateFlag>
<ReceiptType>2</ReceiptType>
</Scr>
Property Description
RcptW Receipt Width species the maximum character limit per receipt content’s line. A termi-
nal’s account is setup with a default receipt width character length. The xed character
limit can be used to center justify the receipt content per line to get the standard receipt
format.
Rcpt Actual EFTPOS receipt content that should be physically printed in case the POS han-
dles the EFTPOS receipt printing. All receipt content should be printed to ensure nan-
cial data integrity.
5.5.2 Receipt Response XML
Example Receipt Response:
<Scr>
<TxnRef>12345</TxnRef>
<TxnType>Receipt</TxnType>
<RcptW>30</RcptW>
<Rcpt> *-----------EFTPOS-----------*18 Apr 18 11:06 CHEQUESWIPE VISA CARD
499999******9103AUTHORISATION 011498REFERENCE 009451PURCHASE AUD1.00TOTAL
AUD1.00 APPROVED PIN VERIFIED *----------------------------*
CUSTOMER COPY PLEASE RETAIN FOR YOUR RECORDS</Rcpt>
</Scr>

Page 20 of 27
6 Fail-Proof Result Notication (FPRN)
Fail-proof result notication (FPRN) is a service that provides additional assurance that the merchant website will
receive notication regarding the outcome of transactions completed via the Windcave host. This service allows
merchant POS to stop checking for the status stage after the transaction is initiated and simply indicate nalization
of the transaction.
FPRN can be enabled by adding <UrlSuccess> and <UrlFail> parameters in the request. Notication will be sent by
Windcave host once the transaction is nalised. Windcave host will only send FPRN notication when the response
result of TxnStatusId is 7 – Verifying Signature and 8 – Display Result. However, it is recommended displaying a user
-friendly prompt such as “Transaction in progress—Please refer to terminal” on the screen of POS. The only case that
the POS would still have to display prompts/buttons is when the terminal must require user selection (TxnStatusId =
7) for approving signature with mandatory button options ‘YES’ and ‘NO’.
As soon as the response result of TxnStatusId is 7 or 8, a background process at Windcave makes an HTTP GET re-
quest to the merchant-nominated success or failure URL. If the merchant web site is unreachable or returns any
HTTP status code other than 200, 201, 302, 303, 404 or 502 the HTTP GET is retried up to a maximum of six times. It
will give up immediately on receiving a 404 (page not found) HTTP status code or 502 (Bad Gateway) HTTP status
code. A 500 HTTP status code, indicating a temporary problem at the client site, will cause a retry.
Please note that merchant POS would still have to perform the status request after the transaction is initiated if they
want to update prompts for every stage on the screen of POS.
To ensure that the web application is in the best position to acknowledge the outcome of every transaction, certain
guidelines should be followed.
The merchant web application should not;
 Filter or base any conditional logic upon the originating IP address (this can vary)
 Depend upon receiving one and only one request for the success/fail URL from the Windcave FPRN system
(multiple requests may be sent).
N.B. The URL at which the merchant website will process FPRN requests must be exposed via standard inter-
net ports i.e. port 80 or port 443 for SSL/TLS trac. When specifying UrlSuccess and UrlFail values do not
specify a non-standard port number within the URL.
Example Transaction Request with FPRN:
<Scr action="doScrHIT" user="xxx" key="yyy">
<Amount>1.05</Amount>
<Cur>NZD</Cur>
<TxnType>Purchase</TxnType>
<Station>1234567890</Station>
<TxnRef>123</TxnRef>
<DeviceId>Device 1</DeviceId>
<PosName>POS 1</PosName>
<PosVersion>Pos V1</PosVersion>
<VendorId>PXVendor</VendorId>
<MRef>My Reference</MRef>
<UrlSuccess>https://webhook.site/d85dd2b9-c1c0-4a5f-8109-bcf8b22eaab6??txnRef=12345&station=1234567890</
UrlSuccess>
<UrlFail>https://webhook.site/d85dd2b9-c1c0-4a5f-8109-bcf8b22eaab6?txnRef=12345&station=1234567890</UrlFail>
</Scr>