For new integrations please refer to the REST API Guide.
PxFusion is a product that allows merchants to accept credit card details within a form on their own web page. The form posts sensitive data directly to Windcave Windcave will process the transaction and cause the user's browser to return to the merchant website in a way that is totally transparent to the cardholder.
The process workflow can be broken down into three main steps:
The following resources are exposed by Windcave for live transactions:
When consuming the PxFusion web service please ensure that your web service stack supports lax versioning: that is, it does not throw exceptions for new unknown data members in received data. Also, ensure that your application does not perform schema validation against an expected schema before attempting to send or process messages.
Windcave have implemented a MPI (Merchant Plug-In) that securely allows an automatic 3D Secure redirection with no development cost or hassle to the merchant whatsoever.
The MPI is compliant with the latest 3D Secure technology. Card schemes estimate that with these new security mechanisms in place, merchants will experience an increase in sales generated, lower operational costs and fewer charge backs due to fraudulent transactions.
Note to support 3DS on the account, please ensure merchants contact our Sales and Support team to enable live 3D Secure with the 3DS settings and credentials which are usually supplied by the merchant's bank or acquirer. Usually 3D Secure validation is tested on the live gateway account with the live credit card details.
A web services descriptor language (WSDL) file is an XML document that describes the arguments accepted by a specific web service as well as the methods and properties supported by that service. The WSDL specification provides the grammar and syntax rules for WSDL files. For the WSDL schema please see https://sec.windcave.com/pxf/pxf.svc?wsdl.
The WS control offers a number of methods to initiate transactions, connect to the Windcave Server and alter settings and retrieve information. This section details the available SOAP operations and their uses.
The merchant’s integrated application or server sends a server-side SOAP HTTP POST to the GetTransactionId web service call. The data submitted will not include sensitive card data such as card number, expiry date, CVC, card holder name and issue number. This data is not collected by, and is never available to, the merchant website.
Please review the GetTransactionId WSDL specifications. The sample call is provided below.
Please ensure the fields elements within the tranDetail element in the SOAP GetTransactionId have to be in alphabetical order as shown in the WSDL. Failure to ensure alphabetical ordering of fields can cause some fields to not be registered.
Element | Required | Description |
---|---|---|
amount | Yes | Amount of transaction in 1.23 format. |
currency | Yes | Specify the currency here. |
password | Yes | Password issued by DPS. |
returnUrl | Yes | The URL (with protocol prefix) to which the users browser should be directed once a transaction has been attempted. Max length 255 char. |
txnRef | Yes | Set by client to uniquely identify transaction. Used in order to process voids. |
txnType | Yes | Purchase / Auth. |
username | Yes | Username issued by DPS. |
enableAddBillCard | Optional | Needed for recurring billing transactions when adding a card to the Windcave system. Value: 'True' or 'False' |
avsAction | No | Address Verification System property. Valid values are 0 1 2 & 3. |
avsPostCode | No | Address Verification System property. Post Code that is listed on the customer's bank statement. |
avsStreetAddress | No | Address Verification System property. Address that is listed on the customer's bank statement. |
billingId | No | Specified for token billing transactions |
dateStart | No3 | The Issue date of the customer's credit card if Issuer requires this field to be present. |
enableAvsData | No2 | Address Verification System property. Values are 1 (Enable Verification) 0 (Disable Verification). |
enablePaxInfo | No | Used for Airline Reservation Systems. Enable collection of extended booking data to go through to the acquirer if they support it. |
merchantReference | No | 64 character free text field |
PaxCarrier PaxCarrier1 | ||
PaxCarrier2 PaxCarrier3 | No | Used for Airline Reservation Systems. 2 character airline identifier. |
paxClass1 paxClass2 | ||
paxClass3 paxClass4 | No | Used for Airline Reservation Systems. Class flight information. |
PaxDate2 PaxDate3 PaxDate4 | No | Used for Airline Reservation Systems. Flight date information. |
paxDateDepart | No | Used for Airline Reservation Systems. Date departing in YYYYMMDD format. |
paxFareBasis1 paxFareBasis2 paxFareBasis3 paxFareBasis4 | No | Used for Airline Reservation Systems. Fare Basis flight information. |
paxFlightNumber1 paxFlightNumber2 | ||
paxFlightNumber3 paxFlightNumber4 | No | Used for Airline Reservation Systems. Flight number information. |
paxLeg1 paxLeg2 paxLeg3 paxLeg4 | No | Used for Airline Reservation Systems. Leg 1 flight information. |
paxName | No | Used for Airline Reservation Systems. Passenger Name. |
paxOrigin | No | Used for Airline Reservation Systems. Passenger Origin. |
paxStopOverCode1 paxStopOverCode3 | ||
paxStopOverCode3 paxStopOverCode4 | No | Used for Airline Reservation Systems. Stop over code flight information. |
paxTicketNumber | No | Used for Airline Reservation Systems. Passenger Ticket Number. Format: AAATTTTTTTTTTC. |
PaxTime1 PaxTime2 | ||
PaxTime3 PaxTime4 | No | Used for Airline Reservation Systems. Time departing. |
paxTravelAgentInfo | No | Used for Airline Reservation Systems. Travel Agent description field. |
timeout | No | A timestamp indicating a time after which if attempted the transaction will not be processed. Deprecated in favour of CancelTransaction. |
transactionDetailsFields | No | The XML element to define the array of transaction details fields to enhance the usage of sessions and transactions depending on use cases. |
transactionDetailsField | No | The XML element to define the array item that specifies the fieldName and fieldValue. |
fieldName | No | Within the element transactionDetailsField specifies the XML element to specify field's name. Possible string options: DebtRepaymentIndicator - Only send this field and set it to 1 to indicate that a debt repayment transaction is to be processed. Otherwise it will be set to 0 by default. EmailAddress – field to indicate setting the card holder’s email address. InstallmentCount - Number value is used to indicate the total number of payments for an installment transaction. For example if the consumer is making 12 installment payments for total payment then this value should be set to 12. Only used for installment based payments. InstallmentNumber - Number value that is used to indicate the current payment number for an installment transaction. For example if the consumer is making payment 1 of 12 then this value should be set to 1. Only used for installment based payments. RecurringMode – specifies the card storage reason on tokenisation (storing a card) and rebilling (rebilling card with a token) requests. Please see Token Billing section for possible string values and their usage details. |
fieldValue | No | Within the element transactionDetailsField the XML element to specify field's value after the fieldName XML element. Valid value options for fieldName: DebtRepaymentIndicator - set it to 1 to indicate that a debt repayment transaction is to be processed. Otherwise set to 0 or do not specify as it will be set to 0 by default. EmailAddress – set a valid email address of the cardholder to send the confirmation email about the payment transaction outcome. InstallmentCount – value to specify total the installment payments count. InstallmentNumber – value to specify current installment payment iteration number. RecurringMode – exact values defined in the Token Billing section. |
txnData1 | No | Optional Free Text. |
txnData2 | No | Optional Free Text. |
txnData3 | No | Optional Free Text. |
The response to the GetTransactionId call will include an indication of the success of the operation and an ID relating to the session created. If the success element value is false then the merchant application need not look to the other properties, the call should be re-tried and brought to the attention of site administrators if attention is needed.
The SessionId property is a random identifier (which is not feasibly guessable) to be used for presentation within the form and URL presented on the client-side. The TransactionId property has been deprecated. It is expected that the merchant application stores the SessionId within their system.
These Elements are given when the GetTransactionId method returns results.
Element | Description |
---|---|
sessionId | Transaction identifier. |
success | Indicates if the GetTransactionId call was successful or not. Either True or False. |
transactionId | Transaction identifier. |
The merchant will make a server-side SOAP HTTP POST to the web service. The call will prevent a transaction taking place for a given sessionId.
The input properties for this CancelTransaction call are described below.
Element Required | Description |
---|---|
username | Yes Username issued by DPS. |
password | Yes Password issued by DPS. |
transactionId | Yes Transaction/Session Id to be cancelled. |
A single property named Success is returned in response to the CancelTransaction call.
Element | Description |
---|---|
cancelTransactionResult | Specifies the result of the cancelTransaction call. Either True or False. |
The merchant’s website or application has to dynamically render a form on a web page which will POST sensitive card data directly to Windcave® securely using HTTPS (SSL Certificate required). Currently the AJAX based POST is not permitted. The following input elements should be included in the form:
Element Required | Type | Max Length |
---|---|---|
CardNumber | Yes | Numeric 19 |
ExpiryMonth | Yes | Numeric 2 |
ExpiryYear | Yes | Numeric 2 |
SessionId | Yes | Alphanumeric N/A |
CardHolderName | No | Alphanumeric 64 |
Cvc2 | No | Numeric 4 |
IssueNumber | No | Numeric 3 |
UserTxnData1 | No | Alphanumeric 255 |
UserTxnData2 | No | Alphanumeric 255 |
UserTxnData3 | No | Alphanumeric 255 |
Upon receiving the HTTP POST from the form at https://sec.windcave.com/pxmi3/pxfusionauth Windcave will process the transaction. The posted data is validated and combined with the other information supplied previously using the sessionId supplied in the hidden field.
Windcave will process the transaction to the acquirer in real-time. When the transaction is processed, typically in under 2 seconds, Windcave will direct the user's browser to the returnUrl supplied in the GetTransactionId call.
In order to obtain the full URL with which to direct the user and notify the merchant of the transaction having taken place Windcave take the returnUrl supplied with the initial SOAP web service call and appends a 'sessionid' query string value.
For example if the returnUrl originally supplied was:
https://www.mysite.com/returnpage.php?ses=1234
And the sessionId for the transaction is 0000060001207174fc003a0a60bd3306; The URL to which the user will be returned is:
https://www.mysite.com/returnpage.php?ses=1234&sessionid=0000060001207174fc003a0a60bd3306
Upon receiving a request for the returnUrl the merchant is in a position to be able to update their records in recognition of the transaction and/or present the result to the user. To do so the merchant must make a GetTransaction SOAP call. The merchant populates the tranasctionId parameter of the GetTransaction SOAP call with sessionId value contained within the query string.
Element | Required | Description |
---|---|---|
username | Yes | Username issued by DPS. |
password | Yes | Password issued by DPS. |
transactionId | Yes | Transaction/Session Id supplied in the query string. |
The GetTransaction call response properties are as follows.
Element | Description |
---|---|
amount | Amount of transaction in 1.23 format. |
authCode | Authorisation Code (up to 64 character alphanumeric). |
billingId | Specified for token billing transactions. |
cardHolderName | Card Holder Name as on Card. |
cardName | Card used (Visa MasterCard Bankcard etc). |
cardNumber | Truncated card number. |
cardNumber2 | A token which can be generated by Windcave when adding a card for recurring billing. |
currencyId | Numeric currency identifier. |
currencyName | Three character currency code. |
currencyRate | Currency rate. |
cvc2ResultCode | Contains information regarding verification of cvc2. |
dateExpiry | Expiry date of card in 4 digit MMYY format. |
dateSettlement | Date transaction will be settled to Bank Account in YYYYMMDD format. This is supported for most but not all banks and card acquirers. If the DateSettlement is not available from the banking network the DateSettlement will contain the current calendar date. |
dpsBillingId | The Billing Id generated by Windcave when adding a card for recurring billing. Needed for rebilling transactions when you do not use your own BillingId. |
dpsTxnRef | Unique identifier for the transaction. Required for programmatic completions and refunds. |
merchantReference | Merchant reference if specified. |
reco | 2 character response code. |
responseText | Response Text associated with ReCo. |
status | Status of transaction. See potential values below. |
sessionId | Identifier returned by GetTransactionId call and submitted in GetTransaction request. |
testMode | Mode indicator. |
transactionId | The transactionId that is being queried. |
txnData1 | Value supplied in either form post or in GetTransactionId call. |
txnData2 | Value supplied in either form post or in GetTransactionId call. |
txnData3 | Value supplied in either form post or in GetTransactionId call. |
txnType | Purchase Auth. |
Windcave supports Authorisation and Complete transaction types. An Auth transaction verifies that funds are available for the requested card and amount, and reserves the specified amount. A Complete transaction is sent at a later date to cause funds transfer for the previously authorised amount, or a smaller amount if the total original value is no longer required. This transaction set is useful when the merchant needs to ensure that funds up to a certain limit are available but the actual total amount is not yet known or goods or services have not yet been delivered.
1) Authorization
Use the GetTransactionId operation with TxnType set to "Auth" for the amount to be authorised. The Auth response contains a DpsTxnRef. The funds are not transferred from the cardholder account.
2) Complete
After a successful Auth transaction, but within 7 days maximum, a Complete transaction must be sent containing the DpsTxnRef returned by the Auth transaction. This can be done using either PX Post, AUTH SSL, a Web Service or Payline/Payment manager (manual option).
Token Billing allows for regular billing of a cardholder card, under the control of the merchant, without requiring the merchant to either store sensitive card data securely or to obtain credit card details every time a new payment is requested. This functionality is implemented by providing the ability for a merchant to request Windcave to capture and store credit card number and expiry date and to link these stored details to a merchant supplied "BillingId".
The DpsBillingId is the default token type generated by Windcave not the merchant. A DpsBillingId will be generated for every transaction where the credit card information is to be stored (indicated by EnableAddBillCard field flag). The returned value will be 16 characters in length and is unique. The merchant can choose to use the DpsBillingId or their own BillingId.
The BillingId is a 32 character field that contains a reference that is unique to the merchant's customer that will be associated with the credit card information stored securely at Windcave. This is undertaken during the Setup Phase. For subsequent charges to the card (Rebill Phase), the merchant does not need to supply the card number or expiry date, only the BillingId originally associated during the Setup Phase.
CardNumber2 is a token generated by Windcave and associated with card details supplied. It is 16 numeric characters and conforms to a Luhn "mod 10" algorithm. This makes it ideal for storage within the database in place of a card number where the value is validated against checks which might normally be made against credit card numbers. A CardNumber2 value is always unique for a given card number. Should a card number be presented for tokenization multiple times the same CardNumber2 value will be returned.
CardNumber2 tokens are generated for all transactions once enabled by Windcave (please contact your Windcave account manager to discuss). The token number will be returned in the cardNumber2 property of the GetTransaction result.
Charging a CardNumber2 token involves a request from the merchant application or Batch processor including an appropriate cardNumber2, a TxnType (Purchase) and the amount to be charged (an optional MerchantReference can be added for reporting purposes). EnableAddBillCard value will need to be set to "False" (or 0) for the rebill phase. Windcave retrieves the credit card number and expiry date stored in the Setup Phase and a purchase transaction is formatted and processed to the card acquirer.
CardNumber2 transactions use the card expiry date stored with the token regardless of whether one is passed through in the transaction data. Once a successful transaction is processed using the real card number associated with a CardNumber2 token the expiry date stored with this token will be updated to that which was used to process the transaction. If your client application displays details of stored tokens to cardholders eg: masked number and expiry date, it is advisable upon a successful transaction for the merchant application to update the expiry date that is stored with the generated token.
1) Setup Phase
The setup phase consists of loading a card into Windcave with a transaction. The transaction can be a Purchase or Validate or Auth transaction type. The transaction can be an online $0.00 Validate which will only process a non-financial (zero dollar or no hold) transaction that is used check that the card and cardholder’s account is valid. If the processing bank or acquirer does not support Validate then the Validate transaction request will be converted to an Auth transaction automatically.
Alternatively a $1.00 Auth transaction type request will determine that the card is valid and not on hot or stolen card lists but depending on the processing bank or acquirer the transaction may incur a temporary financial hold of the transaction amount.
The Purchase transaction type is used if the card is to be charged with an amount and tokenised at the same time.
To add a card for future rebilling, please include the following XML elements in the GetTransactionId web service call:
In the RecurringMode request field, please set one of the card storage reason as the string listed below.
When tokenising the card, please set one of the following:
RecurringMode | Usage explanation |
---|---|
credentialonfileinitial | Cardholder will save card and for future orders the cardholder selects to reuse the saved card for the one-off payment. |
unscheduledcredentialonfileinitial | Cardholder will save their card and for future order based on an event (such as topup) the merchant will reuse the saved card on behalf of the cardholder for the one-off payment. |
recurringinitial | Cardholder will save their card and merchant will reuse the saved card on behalf of cardholder for the subscribed recurring payments. |
installmentinitial | Cardholder will save their card and merchant will reuse the saved card on behalf of cardholder for the installment payments. |
Please discuss with our Implementation and Sales team about your tokenisation use cases if you are unsure. The RecurringMode string value should be set based on the merchant’s business case for tokenising.
You can supply your own billing ID in the BillingId field or leave it blank and use the DpsBillingId returned in the response. We also recommend sending the unique txnRef and a merchantReference. This will make searching and identifying tokens/cards much easier.
Setup Token sample GetTransactionId web service call with RecurringMode in extra transaction details fields
2) Rebill Phase
The merchant application or Batch processor requests a new transaction and supplies the appropriate DpsBillingId or CardNumber2 or BillingId, RecurringMode (to specify the reason for rebilling with the token), MerchantReference (which appears on reports), and the amount to be charged using either PxPost or the Web Service API. EnableAddBillCard value will be set to "False" (or 0) for the rebill phase.
Windcave retrieves the credit card number and expiry date stored in the Setup Phase and a purchase transaction is formatted and processed to the card acquirer.
If transactions are being processed to an acquirer that supports and is configured for recurring transactions, the Windcave account can also be setup to process recurring transactions only.
The main advantage of recurring transactions is that the ExpiryDate is not required. This further reduces the amount of data that needs to be stored for a merchant, and bypasses the issue of expired cards.
To setup your Windcave account for recurring transaction processing only, please contact [email protected] (note: please ensure that your merchant bank account has been setup for recurring transactions).
PX Fusion is capable of handling extended booking information, which is used to display flight data on cardholders statements.
If you would like to add booking information to your transaction details you will need to set the EnablePaxInfo input property to "True" (or 1) and you will be able to use the following properties -
The following pre-approved 'test card' numbers can be used for testing, within test environments.
Note: These are only suitable for Windcave test accounts.
The following section provides a detailed description of each PX Fusion element and indicates if it used as an input or output. If a property is marked as input, it is not included in the response to GetTransaction.
Amount (input/output) Datatype: String Max 12 characters
Total Purchase, Refund, Auth or Complete amount. Format is d.cc where d is dollar amount (no currency indicator) and cc is cents amount. for example, $1.80 (one dollar and eighty cents) is represented as "1.80", not "1.8". A string value is used rather than the conventional Currency Datatype to allow for easy integration with Web applications. Maximum value allowable is $99,999.99. Note that acquirer or card limits may be lower than this amount. When submitting transactions for currencies with no decimal division of units such as JPY the AmountInput must be in an appropriate format e.g. "10".
AuthCode (output) Datatype: String Max 22 characters
Authorization code returned for approved transactions.
AvsAction (input): 1 digit
Address Verification System property. Valid values are 0, 1, 2 & 3.
The value will most likely be 1 for most circumstances.
AvsPostCode (input) Datatype: String Max 20 characters
Address Verification System property. Post Code that is listed on the customer's bank statement.
AvsStreetAddress (input) Datatype: String Max 60 characters
Address Verification System property. Address that is listed on the customer's bank statement.
BillingId (input/output) Datatype: String Max 32 characters
BillingId generated by the customer system. This could be a customer number and is used as input to SubmitTransaction to rebill an existing customer. If EnableAddBillCard
CardHolderName (input) Datatype: String Max 64 characters
The cardholder name as it appears on customer card; Optional and may be left blank.
CardNumber (input) Datatype: String Max 20 characters
The card number. No leading or embedded blanks are permitted. Must contain a numeric value.
CardName (output) Datatype: String Max 16 characters
The card type used for the transaction. Note that the list may be expanded as support for new cards is added. The CardName format is to capitalize the first letter with remaining letters in lowercase.
CardName Value | Description |
---|---|
Amex | American Express |
Bankcard | Bank Card |
Diners | Diners Card |
Jcb | JCB |
Mastercard | Mastercard |
Visa | Visa |
CardNumber2 (output) Datatype: String Max 19 characters
A token generated by Windcave when adding a card for recurring billing. CardNumber2 is a 16 digit number which conforms to a Luhn 'mod 10' algorithm and has a 1-to-1 relationship with the actual card number used. To use CardNumber2 tokens your account must be configured to generate them. Please contact our support team if you intend to use this feature.
Currency (input/output) Datatype: String Max 4 characters
Indicates currency used for this transaction. If blank, currency will be determined by the bank account used which is selected using the Username/Password details. Not all acquirers can support multiple currencies. Valid values for Currency are:
CAD | Canadian Dollar |
---|---|
CHF | Swiss Franc |
DKK | Danish Krone |
EUR | Euro |
FRF | French Franc |
GBP | United Kingdom Pound |
HKD | Hong Kong Dollar |
JPY | Japanese Yen |
NZD | New Zealand Dollar |
SGD | Singapore Dollar |
THB | Thai Baht |
USD | United States Dollar |
ZAR | Rand |
AUD | Australian Dollar |
WST | Samoan Tala |
VUV | Vanuatu Vatu |
TOP | Tongan Pa'anga |
SBD | Solomon Islands Dollar |
PGK | Papua New Guinea Kina |
MYR | Malaysian Ringgit |
KWD | Kuwaiti Dinar |
FJD | Fiji Dollar |
CurrencyId (input) Datatype: String Max 4 characters
Indicates the input currency's numeric ISO currency code.
CurrencyRate (Output) Datatype: String Max 3 characters
Charge rate, if applicable.
Cvc2ResultCode (Output) Datatype: String 1 character
Depending on the response code, the merchant can make a more informed decision on the payment that has taken place. Please see below table for interpretation of response codes:
RESPONSE COD | E DEFINITION | DEFINITION |
---|---|---|
M | CVC matched. | You will want to proceed with transactions for which you have received an authorisation approval. A CVC match indicates the values provided matches the Issuing Banks details |
N | CVC did not match. | You may want to follow up with the cardholder to verify the CVC value before completing the transaction even if you have received an authorisation approval. The CVC details provided by the Cardholder do not match their Issuing Banks details |
P | CVC request not processed. | Issuing Bank is unable to process CVC at this time |
S | CVC should be on the card but merchant has sent code indicating there was no CVC. | You may want to follow up with the cardholder to verify that the customer checked the correct location for the CVC. If the transaction is Approved you may also wish to consider not fulfilling the transaction |
U | Issuer does not support CVC. | The card Issuing bank does not support CVC process |
DateExpiry (output) Datatype: String Max 4 characters
Indicates card expiry date. Format is MMYY where MM is month 01-12 and Year 00-99. do not insert "/" or other delimiter. Not required for Complete or Refund transactions.
DateSettlement (output) Datatype: String Max 8 characters
Indicates Date of settlement (when money will be deposited in Merchant bank account) if this is supported by the Acquirer, otherwise contains the date the transaction was processed in YYYYMMDD format.
DateStart (input) Datatype: String Max characters
The Issue date of the customer's credit card, if Issuer requires this field to be present.
Format is MMYY where MM is month 01-12 and Year 00-99. do not insert "/" or other delimiter.
Used for Maestro/Solo cards.
EnableAddBillCard (input) Datatype: Boolean True/False
If set to "True" (or 1) on input to GetTransactionId, the details necessary to charge the same customer in the future are securely stored. A BillingId may optionally be attached on input. A DpsBillingId is returned. See Token Billing section for details on using this feature.
EnableAvsData (input) Datatype: Boolean True/False
Address Verification System property. Values are 1 (Enable Verification), 0 (Disable Verification). Your bank may require that you use AVS, in which case you will need to set to 1.
EnableMandatoryCVC2 (input) Datatype: Boolean True/False
When enabled, mandates a CVC2 value in the form post, will return a decline if a CVC2 value is not submitted. Note: The PX Fusion account setting may need to be set to enable this. Please contact the Support team to enable this.
EnablePaxInfo (input) Data type: Boolean True/False
Used for Airline Reservation Systems. Enable collection of extended booking data to go through to the acquirer. Value will need to be true (1) if ticket information is included with the transaction.
DpsBillingId (input/output) Datatype: String Max 16 characters
Returned for a successful billing transaction if EnableAddBillCard is set. Supplied as input to rebill a transaction if BillingId is not used. It is not allowed to specify both a BillingId and a DpsBillingId when rebilling a transaction.
DpsTxnRef (output) Datatype: String Max 16 characters
Returned for every transaction. If the transaction was approved, DpsTxnRef can be used as input to a Refund transaction. Used to specify a transaction for refund without supplying the original card number and expiry date.
MerchantReference (input/output) Datatype: String Max 64 characters
Free Text Field for use by merchant (could be order number, customer number etc.).
Password (input) Data type: String Max 64 characters
Used with Username to determine account for settlement. Windcave clients can be set up with more than one bank account. Each transaction may be designated for a specific account if required.
PaxCarrier (input) Data type: String Max 2 characters
Used for Airline Reservation Systems. Carrier flight information. Alphanumeric.
PaxCarrier2 - 4 (input) Data type: String Max 2 characters
Used for Airline Reservation Systems. Carrier flight information. Alphanumeric.
PaxClass1 - 4 (input) Data type: String Max 1 characters
Used for Airline Reservation Systems. Class flight information. Alphanumeric.
PaxDate2 - 4 (input) Data type: String Max 20 characters
Used for Airline Reservation Systems. Leg depart date flight information. Alphanumeric.
PaxDateDepart (input) Data type: String Max 8 characters
Used for Airline Reservation Systems. Date departing in YYYYMMDD format. Numeric.
paxFareBasis1 - 4 (input) Data type: String Max 6 characters
Used for Airline Reservation Systems. Fare basis flight information. Alphanumeric.
paxFlightNumber1 - 4 (input) Data type: String Max 6 characters
Used for Airline Reservation Systems. Flight number information. Alphanumeric.
PaxLeg1 - 4 (input) Data type: String Max 3 characters
Used for Airline Reservation Systems. Flight number information. Alphanumeric.
PaxName (input) Data type: String Max 20 characters
Used for Airline Reservation Systems. Passenger Name. Alphanumeric.
PaxOrigin (input) Data type: String Max 3 characters
Used for Airline Reservation Systems. Passenger Origin of departure. Alphanumeric.
PaxStopoverCode1 - 4 (input) Data type: String Max 1 characters
Used for Airline Reservation Systems. Stop over code flight information. Alphanumeric.
PaxTicketNumber (input) Data type: String Max 10 characters
Used for Airline Reservation Systems. Passenger Ticket Number. Format: AAATTTTTTTTTTC. AAA is airline code, TTTTTTTTTT (10 chars) is actual ticket number and C is check digit. Numeric.
PaxTime1 - 4 (input) Data type: String Max 4 characters
Used for Airline Reservation Systems. Leg depart time flight information. Alphanumeric.
PaxTravelAgentInfo (input) Data type: String Max 25 characters
Used for Airline Reservation Systems. Travel Agent description field. Also known as the Booking Reference on some of Windcave screens. Alphanumeric free text field.
ResponseCode (output) Datatype: String Max 2 characters
Response Code generated by Windcave Server (for locally declined transactions) or by the Card Acquirer (for host originated responses). The ReCo should not be checked by the client application, as these values differ according to acquirer. Use the Success property to check for successful finishing of a transaction. Refer to the Response Codes section for a list of valid response code errors generated by Windcave.
ResponseText (output) Datatype: String Max 32 characters
Response Text associated with the response code of the transaction
ReturnUrl (input) Datatype: String Max 255 characters
URL (with protocol prefix) that the user will be forwarded to once the card details are submitted (with the session ID appended).
SessionId (output) Datatype: String Max 32 characters
Unique transaction identifier that is returned after a successful GetTransactionId call and used to obtain Transaction results using GetTransaction.
Status (output) Datatype: Integer Max 1 character
The status property contains an integer indicating the status of the GetTransactionId call and transaction associated with it. Possible values for the status property are as follows.
Value | Detail |
---|---|
0 | Transaction approved. |
1 | Transaction declined. |
2 | Transaction declined due to transient error (retry advised). |
3 | Invalid data submitted in form post (alert site admin). |
4 | Transaction result cannot be determined at this time (re-run GetTransaction). |
5 | Transaction did not proceed due to being attempted after timeout timestamp or having been cancelled by a CancelTransaction call. |
6 | No transaction found (SessionId query failed to return a transaction record - transaction not yet attempted). |
TransactionId (output) Datatype: String Max 32 characters
Unique transaction identifier that is returned after a successful GetTransactionId call and used to obtain Transaction results using GetTransaction.
TransactionDetailsFields (input) Datatype: String
The XML element to define the array of transaction details fields to enhance the usage of sessions and transactions depending on use cases.
TransactionDetailsField (input) Datatype: String
The XML element to define the array item that specifies the fieldName and fieldValue XML elements.
FieldName (input) Datatype: String
Within the element transactionDetailsField, the XML element to specify field's name.
FieldValue (input) Datatype: String
Within the element transactionDetailsField, the XML element to specify field's value after the fieldName XML element.
TxnData1, TxnData2, TxnData3 (input/output): String Max 255 characters
Optional free text fields. Usually assigned at origin website.
TxnRef (input/output) Datatype: String Max 16 characters
A unique identifier provided by your application to uniquely identify the transaction. This is the TxnRef supplied by the client to initiate the transaction, or, if not supplied, a TxnRef value internally generated by Windcave on return.
TxnType (input/output) Datatype: String Max 8 character
Value | Meaning |
---|---|
Validate | Validates the card and account with no financial transaction or hold of funds. Only used to tokenise the card in Token Billing setup phase. |
Auth | Authorise - amount is authorised no funds transferred. |
Purchase | Purchase - Funds are transferred immediately. |
Username (input) Data type: String Max 32 characters
Used with Password to determine account for settlement. Windcave clients can be set up with more than one bank account. Each transaction may be designated for a specific account if required.