PxFusion

PxFusion

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:

  • Obtaining a TransactionID (via a Web Service).
  • Using a HTML form to POST sensitive data directly to Windcave using the TransactionId as the identifier.
  • Obtaining the results of the transaction using the TransactionId (via a Web Service).

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.

PxFusion - Technical SpecificationPxFusion - Demo Page

PX Fusion - Work Flow

3D Secure Support

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.

WSDL

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.

SOAP Operations

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.

GetTransactionId

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.

Input Elements

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.

Output Elements

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.

CancelTransaction

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.

Input elements

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.

Output Elements

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.

Rendering the Form

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:

Input Elements

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
The card detail input values are set by the user as they complete the fields. The SessionId returned by the GetTransactionId call should be included as the value of a hidden input named 'SessionId' within the form. Windcave will ignore any extraneous variables included within the data posted by the form. UserTxnData1 - 3 fields will be stored by Windcave only where no values were passed to Windcave within the TxnData1 - 3 fields within the GetTransactionId request.

Transaction Result

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

GetTransaction

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.

Input Elements

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.

Output Elements

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.

Auth-Complete

Overview

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.

Operation

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

Overview

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:

  • enableAddBillCard - set to 1 when adding a card
  • RecurringMode – required to be set within the transactionDetailsField as shown in the example request below
  • billingId (optional – recommended to parse the dpsBillingId returned in the response instead)

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.

Recurring Transactions

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).

Extended Airline Booking Data

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 -

Test Cards

The following pre-approved 'test card' numbers can be used for testing, within test environments.

  • Visa - 4111111111111111
  • MasterCard - 5431111111111111
  • Amex - 371111111111114
  • Diners - 36000000000008

Note: These are only suitable for Windcave test accounts.

Properties Description

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.

  • 0 - Do not check AVS details with acquirer, but pass them through to Windcave only for the record.
  • 1 - Attempt AVS check. If the acquirer doesn't support AVS or AVS is unavailable, then the transaction will proceed as normal. If AVS is supported and the AVS check fails, then the transaction will be declined.
  • 2 - The transactions needs to be checked by AVS, even if isn't available, otherwise the transaction will be blocked.
  • 3 - AVS check will be attempted and any outcome will be recorded, but ignored i.e. transaction will not be declined if AVS fails or unavailable.
  • 4 - Attempt AVS check. If the acquirer doesn't support AVS or AVS is unavailable, then the transaction will proceed as normal. If AVS is supported and the AVS check fails with a response of “N” (address and postcode both do NOT match what issuer has on file), then the transaction will be declined. Partial AVS matches such as postal code only matches or address only matches will be accepted.

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.