Identifier assigned by Heartland during the boarding process; used for chaining sites together

Identifier assigned by Heartland during the boarding process; tied to a specific merchant ID

Identifier assigned by Heartland during the boarding process

User name assigned by Heartland during the boarding process

Password for the associated user; a temp password will be provided during the boarding process but must be altered before it is used for transaction processing

The credential token is used to indicate a user session. Currently, this option is only available to internal Heartland applications and should not be used by integrators.

This element can be used by the client to provide a value that can be searched for later. Clients are free to provide any value that is useful to them but it must not contain sensitive data. This will also be echoed in the response if present.

Identifier assigned by Heartland during the certification process; this field is optional to support legacy integrations, but all new integrations require this value.

Software version number assigned by Heartland during the certification process; this field is optional to support legacy integrations, but all new integrations require this value.

Identifier assigned by the merchant or client to the clerk running this transaction; this must not contain sensitive data

GPS coordinates indicating the location of the source of the transaction

A client-generated transaction id. This must be unique for this device. If present, it will be attached to this transaction and echoed in the response. This allows the client to run a timeout reversal against a unique transaction in the event that a response is never received. When a response is received, the client will receive a gateway-generated transaction id.

A client-supplied device identifier to be sent when transactions for multiple devices are aggregated in the same batch. If present, the field will be sent to the issuer on authorization and settlement requests and echoed in the response header.

SAFData indicating if a transaction that was processed and initiated in "store and forward" (SAF) mode.

API key that can be used in place of license, site, device, username, and password. An API will be tied to a specific environment (i.e. certification or production).

Note: The use of SecretAPIKey is restricted.

POS request date and time. Required for Interac processing.

Note:This field is required for Canadian merchants.

Device capabilities and/or attributes needed by a Host processor that are not otherwise able to be determined. Please refer to the Developer Guide for further details as this data may be required for certain Host processors..

A client-generated transaction id used for certain API integrations. If present, it will be attached to this transaction and echoed in the response.

Note: This is for internal use only.

A client-generated transaction id used for certain API integrations. If present, it will be attached to this transaction and echoed in the response.

Note: This is for internal use only.

Indicates whether to return a hashed value of the card number using a custom salt value.

Note: This field has been deprecated

AddAttachment can be used to store and associate data (i.e. images and documents) to a prior transaction.

The referenced original transaction must have been approved and must be one of the following:

• CreditAuth
• CreditOfflineAuth
• CreditSale
• CreditOfflineSale
• CreditReturn
• DebitSale
• GiftCardSale
• GiftCardAddValue
• PrePaidAddValue
• CheckSale
• OverrideFraudDecline

This must be done within three months of the original transaction.

For Document attachment types:

• Up to five document attachments are allowed to be associated with a single transaction
• Document attachments can be submitted on one or more requests
• To replace a document attachment, a new document attachment with the same name can be provided

For other attachment types:

• Only one of each attachment type can be associated with a single transaction
• Only one of each attachment type can be submitted per request
• If a request includes an attachment type that is already associated with a given transaction, it will result in the attachment being replaced

AltPaymentAuth takes a unique Session Id and performs an Authorization transaction.

AltPaymentCapture takes a previously approved Alternate Payment Authorization or Alternate Payment Order and captures a portion of the original into the current open batch. If a batch is not open, this transaction will create one.

AltPaymentCreateAuth takes a previously approved Alternate Payment Order transaction and creates an Authorization from it.

AltPaymentCreateSession creates a unique Session for Electronic Commerce Alternate Payment Processing. This service must be called first to perform Alternate payment processing.

AltPaymentOrder takes a unique Session Id and performs an Order transaction.

AltPaymentReturn takes a Alternate Payment GatewayTxnId and performs a a return against that transaction. AltPaymentSale and AltPaymentCapture can be returned.

AltPaymentReversal takes a Alternate Payment GatewayTxnId and performs a reversal against that transaction. Abanonded timed out transactions of AltPaymentSale, AltPaymentOrder, AltPaymentAuth and AltPaymentCapture can be reversed

AltPaymentSale takes a unique Session Id and performs a Sale transaction. The sale is placed in the current open batch. If a batch is not open this transaction will create one.

AltPaymentSessionInfo takes a unique Session Id and returns information about the session.

AltPaymentVoid takes a Alternate Payment GatewayTxnId and performs a void against that transaction. AltPaymentAuth, AltPaymentOrder and AltPaymentCreateAuth can be voided.

Authenticate is used to authenticate a specific user. For this call the header must include username and password.

Note: This is for internal use only.

BatchClose is used to settle and close the current open batch. If a batch is not open an error will be returned.

CancelImpersonation is used to terminate a previously started impersonation session.

Note: This is for internal use only.

CashReturn creates a log of a transaction that is returning cash to a customer. This is processed offline.

Note: The client is responsible for maintaining any required cash value totals for reconciliation.

CashSale creates a log of a transaction, in which cash is collected from a customer. This is processed offline.

Note: The client is responsible for maintaining any required cash value totals for reconciliation.

CheckSale transactions use bank account information as the payment method. There are sub-actions that can be taken as part of the CheckSale as indicated by the CheckAction field.

Note: Both GETI and Colonnade are supported. A check processor is chosen during the boarding process for each device. The choice of check processor will drive the available functionality as well as the required elements. See individual fields for additional information.

CheckQuery is used to query info about a check transaction.

CheckVoid is used to cancel a previously successful CheckSale transaction. It can also be used to cancel a prior CheckSale transaction. This should be used in timeout situations or when a complete response is not received.

Note:CheckVoid transactions should be submitted within 31 days of the original transaction.

Note:If the CheckVoid also fails to return a complete response (likely due to a timeout), wait until connectivity is restored and try again or contact support to ensure the proper result was achieved. CheckQuery can be used to check the status of a prior CheckSale transaction.

ChipCardDecline is used to record an offline decline by an EMV chip card.This transaction is optional and can be used for record-keeping purposes only.

Note:This transaction is not used for a transaction that received an online approval. To cancel transactions that have been approved online but subsequently declined by the chip, a Credit/Debit Reversal must be sent.

CreditAccountVerify is used to verify that the associated account is in good standing with the Issuer. This is a zero dollar transaction with no associated authorization. Since VISA and other Issuers have started assessing penalties for one dollar authorizations, this provides a way for merchants to accomplish the same task while avoiding these penalties.

There are differences in the processing of this transaction based on card type:

• VISA: an account verification is done at the Issuer
• MasterCard: an account status check is done at the Issuer
• Discover: an account verification is done at the Issuer
• AMEX: an AVS only verification is done; this still ensures that the account is valid but requires that AVS data is supplied (zip code at a minimum). Both manual and swiped/track entry methods are supported. However, EMV transactions are not supported.

Note:UnionPay cards do not support Verification when routing directly to UnionPay International for approval. UnionPay cards routing through either the Discover or JCB networks may obtain verification.  (UnionPay direct routing available for Canada merchants on the GSAP authorization platform only).

CreditAdditionalAuth is typically used in a bar or restaurant situation where the merchant obtains the payment information for an original CreditAuth but does not want to hold the card or ask for it on each additional authorization.

This uses data from a previously successful CreditAuth to authorize an additional amount. The additional authorization is run as a card not present transaction and cannot be placed in a batch. This can be repeated as needed. The final settlement amount including any additional authorized amounts must be provided in the CreditAddToBatch for the original CreditAuth. When the original transaction is added to the batch a reversal is automatically attempted for all additional authorizations.

The following rules apply:

• CreditAdditionalAuth is allowed only for restaurant merchants.
• The original transaction must be an approved open authorization run within the same day (i.e. a CreditAuth that has not been added to a batch).
• When the original authorization transaction is fully reversed or voided, any associated CreditAdditionalAuth transactions are reversed.
• An original authorization transaction with CreditAdditionalAuth transactions can be partially reversed for less than the full original auth amount. However, additional authorizations are still not reversed until the original is added to the batch.
• Additional authorizations cannot be voided, edited, or used for returns.

Note:CreditAdditionalAuth is not supported for UnionPay cards routing to UnionPay International for authorization. CreditAdditionalAuth may continue to be used for UnionPay cards routing through either the Discover or JCB networks. (UnionPay direct routing available for Canada merchants on the GSAP authorization platform only).

Note:This service has been deprecated. Refer to CreditIncrementalAuth.

CreditAddToBatch is primarily used to add a previously approved open authorization (CreditAuth, CreditOfflineAuth, OverrideFraudDecline, or RecurringBillingAuth) to the current open batch. If a batch is not open this transaction will create one. It also provides the opportunity to alter data associated with the transaction (i.e. add a tip amount).

Note: The gateway will not submit an authorization or reversal when the settlement amount of a transaction is altered. The client is responsible for managing these adjustments as needed.

CreditAuth authorizes a credit card transaction. These authorization only transactions are not added to the batch to be settled. They can be added to a batch at a later time using CreditAddToBatch. Approved authorizations that have not yet been added to a batch are called open auths.

Note: If you prefer to have the authorization automatically added to the batch, use CreditSale.

Authorizations can be processed by sending card data, the GatewayTxnId from a previous authorization, or a key from a previously stored payment method.

When using a prior transaction id, the following rules apply:

• The original transaction must be an approved CreditAuth or CreditSale that was not also run using a prior transaction id.
• The original transaction must be fully reversed, voided, or returned.
• The original transaction must have occurred within the last 14 days.
• The original transaction may only be referenced once in this way.
• The new amount must be greater than 0.00 and cannot exceed 100% of the original.
• The new transaction is sent as "Card Not Present"
• The new transaction can be voided or reversed.
• OrigTxnRefData must be provided with AuthCode and/or CardNbrLastFour and the provided data must match the original transaction data.

CreditCPCEdit attaches Corporate Purchase Card (CPC) data to a prior transaction. This information will be passed to the issuer at settlement when the associated card was a corporate card or an AMEX card.

Note: This function only works against previously approved CreditAuth, CreditSale, CreditOfflineAuth, CreditOfflineSale, RecurringBilling, and RecurringBillingAuth transactions.

Note: The amount of the original transaction is not altered by the CreditCPCEdit. This additional data is informational only. The original transaction will be processed regardless of whether or not the CreditCPCEdit is used by the client.

CreditIncrementalAuth adds to the authorized amount for a prior transaction.

The following rules apply:

• The original transaction must have been an approved CreditAuth. NOTE: CreditSale is allowed for US merchants processing to the Exchange host only.
• The original transaction id should continue to be used for subsequent transactions (i.e., voids, reversals, edits, etc.); the transaction id of the incremental authorization should never be referred to by subsequent transactions.
• Each incremental authorization is not added to the batch. The total amount is maintained with the original transaction.
• If the final settlement amount of the original transaction is less than the total of all authorizations, reversals will automatically be generated as needed.

Note:UnionPay cards routed directly to UnionPay International do not support Incremental Authorizations. CreditIncrementalAuth may continue to be used for UnionPay cards routing through either the Discover or JCB networks. (UnionPay direct routing available for Canada merchants on the GSAP authorization platform only).

CreditIPQuery is used to query the Installment Payment terms available to the cardholder.

Note: This service is available to merchants in the AP region only.

CreditOfflineAuth records an authorization obtained outside of the gateway (e.g., voice authorization, chip card offline approval). These authorization only transactions are not added to the batch to be settled. They can be added to a batch at a later time using CreditAddToBatch. Approved authorizations that have not yet been added to a batch are called open auths.

Note:Depending on the Host Processor, a CreditOfflineAuth transaction may not be modified after it has been added to a batch.

CreditOfflineSale records an authorization obtained outside of the gateway (e.g., voice authorization, chip card offline approval). The authorization is placed in the current open batch. If a batch is not open this transaction will create one.

CreditReturn allows the merchant to return funds back to the cardholder. Returns can be for the entire amount associated with the original sale or a partial amount. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

For added fraud protection, CreditReturn can be run utilizing the GatewayTxnId from a previous sale. When this feature is used, the gateway tracks returns against the original sale and applies several rules.

The following rules apply when returning by GatewayTxnId:

• The original transaction must be a CreditAuth, CreditSale, CreditOfflineAuth, CreditOfflineSale, RecurringBilling, or RecurringBillingAuth and must be in a batch. It cannot be an open authorization that still needs to be added to a batch.
• The total of all returns cannot exceed the original sale amount. This is true for processing a single return as well as multiple returns against the same original transaction.
• A return amount must be greater than zero.
• The return must be run within 1 year.
• CreditReversal, CreditVoid, and CreditTxnEdit are not allowed against original transactions for which a full or partial return has been run.
• A return can be voided. If this results in the total return amount being adjusted back to zero, CreditVoid, CreditReversal, and CreditTxnEdit are allowed on the original transaction once again.
• If CardData is also supplied, the supplied card number and the card number of the original transaction must match.

Note: If the original transaction is in the current open batch, a CreditVoid or CreditReversal may be used instead. However, only a return can be used once the batch is closed.

CreditReversal cancels a prior authorization in the current open batch. This can be used in timeout situations or when a complete response is not received. This transaction can also be used to cancel a transaction that was approved online but subsequently declined by the chip.

This can be used on prior transactions of the following types: CreditAuth, CreditSale, CreditOfflineAuth, CreditOfflineSale, RecurringBilling, RecurringBillingAuth, and OverrideFraudDecline.

Note:This can also be used to partially reduce the amount of a prior authorization.

Note:Credit reversal transactions must be submitted within 31 days of the original transaction.

Note:If the reversal also fails to return a complete response (likely due to a timeout), wait until connectivity is restored and try again or contact support to ensure the proper result was achieved.

Note:A credit reversal should be requested with the GatewayTxnID or ClientTxnID. Never send a reversal request with a multi-use token in the Card Data.

CreditSale authorizes a credit card transaction. These authorizations are automatically added to the batch to be settled. If a batch is not already open this transaction will create one.

Authorizations can be processed by sending card data or the GatewayTxnId from a previous authorization. When using a prior transaction id, the following rules apply:

• The original transaction must be an approved CreditAuth or CreditSale that was not also run using a prior transaction id.
• The original transaction must be fully reversed, voided, or returned.
• The original transaction must have occurred within the last 14 days.
• The original transaction may only be referenced once in this way.
• The new amount must be greater than 0.00 and cannot exceed 100% of the original.
• The new transaction is sent as "Card Not Present"
• The new transaction can be voided or reversed.
• OrigTxnRefData must be provided with AuthCode and/or CardNbrLastFour and the provided data must match the original transaction data.

CreditTxnEdit allows the merchant to alter the data on a previously approved CreditSale, CreditAuth, CreditOfflineSale, or CreditOfflineAuth (i.e. add a tip amount).

Note:Depending on the Host Processor, a CreditOfflineAuth transaction may not be modified after it has been added to a batch.

Note:The gateway will not submit an authorization or reversal when the settlement amount of a transaction is altered. The client is responsible for managing these adjustments as needed.

Note:Approved UnionPay authorizations routed directly to UnionPay International cannot be adjusted. UnionPay cards routing through either the Discover or JCB networks may be adjusted. (UnionPay direct routing available for Canada merchants on the GSAP authorization platform only).

CreditVoid is used to cancel an open auth or remove a transaction from the current open batch. The original transaction must be a CreditAuth, CreditSale, CreditReturn, CreditOfflineAuth, CreditOfflineSale, RecurringBilling, RecurringBillingAuth, or OverrideFraudDecline.

Note: Once a batch is closed, associated transactions can no longer be voided. In these cases, a CreditReturn can be used to adjust a customer's account.

Note: If a transaction has been fully or partially returned, it cannot be voided.

Note: Due to new issuer regulations, a void now automatically attempts to reverse the original transaction. If the reversal is successful, the original transaction status will be set to 'R'. If there is no need to reverse (i.e. offlines) or the reversal fails, the original transaction status will be set to 'V'. A successful response to the void will indicate that the original transaction has been removed from the batch in either case.

DebitAddValue increases the amount on a stored value card. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

Note: This transaction has been obsoleted. See the PrePaidAddValue for an alternative.

DebitBalanceInquiry returns the available balance for a Debit card. Available for retail devices in the Philippines only.

DebitReturn allows the merchant to return funds from a prior debit sale back to the cardholder. Returns can be for the entire amount associated with the original sale or a partial amount. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

For added fraud protection, DebitReturn can be run utilizing the GatewayTxnId from a previous debit sale. When this feature is used, the gateway tracks returns against the original sale and applies several rules.

The following rules apply when returning by GatewayTxnId:

• The total of all returns cannot exceed the original sale amount. This is true for processing a single return as well as multiple returns against the same original transaction.
• A return amount must be greater than zero.
• DebitReversal is not allowed against original transactions for which a full or partial return has been run.
• The supplied card number (from the track data or token) and the card number of the original transaction must match.

Note: If the original transaction is in the current open batch, a DebitReversal may be used instead. However, only a return can be used once the batch is closed.

DebitReversal cancels a previous DebitSale transaction. This should be used in timeout situations or when a complete response is not received. This transaction can be used to cancel a transaction that was approved online but subsequently declined by the chip.

Note: Debit reversal transactions must be submitted within 31 days of the original transaction.

Note: Partial reversals are not supported for debit transactions.

Note: If the reversal also fails to return a complete response (likely due to a timeout), wait until connectivity is restored and try again or contact support to ensure the proper result was achieved.

DebitAddToBatch is used to add a pre-authorized debit transaction to the open batch. If a batch is not open this transaction will create one.

Note: DebitAuth is only allowed in Canada.

For Future Use.

DebitAuth authorizes a debit transaction. These authorization only transactions are not added to the batch to be settled. They can be added to a batch at a later time by using DebitAddToBatch.

Note: DebitAuth is only allowed in Canada

For Future Use.

DebitSale authorizes a debit card transaction. These authorizations are automatically added to the batch to be settled. If a batch is not already open this transaction will create one.

EBTBalanceInquiry returns the available balance for an EBT account.

EBTCashBackPurchase is used to purchase goods with EBT Cash Benefits. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

EBTCashBenefitWithdrawal is used to disburse cash from an EBT Cash Benefits account. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

EBTFSPurchase is used to purchase goods with EBT Food Stamps/SNAP. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

EBTFSReturn is used to credit previously debited funds to an EBT Food Stamps/SNAP account for merchandise returned. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

EBTFSReversal cancels a prior purchase in the current open batch. This can be used in timeout situations or when a complete response is not received. In either case, the client is unsure of the outcome of the prior transaction.

This can be used on prior transactions of the following types: EBTFSPurchase, EBTFSReturn, EBTCashBenefitWithdrawal and EBTCashBackPurchase.

Note: Partial reversals are not supported for EBT transactions.

Note: If the reversal also fails to return a complete response (likely due to a timeout), wait until connectivity is restored and try again or contact support to ensure the proper result was achieved.

EBTVoucherPurchase is obsolete and should no longer be used

Test for internal use only.

Note: For a quick test, clients can use TestCredentials.

FindTransactions is used to search all current gateway transactions based on provided filter criteria.

Note: When possible, searching should be done by TxnId. This is a single transaction search unless used in conjunction with FindHistoryInd. Any additional criteria is ignored.

Note: The gateway is not a long-term storage service. Generally, data is only available for 90 days; however, recurring billing data is saved for two years. For longer periods, Heartland offers other services. Further information can be provided during boarding and certification.

GetAttachments is used to retrieve attachments (i.e. documents, images, etc.) associated with a particular transaction.

GetTransactionStatus is used to retrieve the status of any gateway transaction.

Note: This is for internal use only.

Note: This is for internal use only.

GiftCardActivate is used to activate a new stored value account and load it with an initial balance. If the specified stored value account is already active, the request will fail.

Note: Stored value accounts can also be activated implicitly via the GiftCardAddValue method depending on the platform configuration for a customer's specific program.

Note: This method supports loyalty points.

GiftCardAddValue loads an amount onto a stored value account. Depending on the gift processor, this request may also be used to automatically activate the account.

Note: This method supports loyalty points.

GiftCardAlias allows the client to manage stored account aliases. An alias is an alternate identifier used to reference a stored value account. Restrictions on the possible values of alias must be obtained from the gift processor.

GiftCardBalance is used to retrieve the balance(s) for each currency supported by a stored value account.

GiftCardCurrentDayTotals is used to retrieve stored value transaction totals for the current day.

Note: This has been obsoleted and should no longer be used. See FindTransactions for an alternative.

GiftCardDeactivate is used to deactivate an active stored value account that otherwise has not been used. Attempts to deactivate an account that is not active or has had activity will fail.

Note: For some gift processors, once a stored value account has been deactivated it can never be re-activated.

GiftCardPreviousDayTotals is used to retrieve stored value transaction totals for the previous day.

Note: This has been obsoleted and should no longer be used. See FindTransactions for an alternative.

GiftCardReplace transfers balances from one stored value account to another. This is typically to replace a lost or stolen account with a new one or to consolidate two or more accounts into a single account. After a transfer has completed, the source account is closed/deactivated and can no longer be used. The balance for the destination account is returned in the response.

GiftCardReversal is used to cancel a prior stored value transaction. This should be used in timeout situations or when a complete response is not received. In either case, the client is unsure of the outcome of the prior transaction.

This can be used on prior transactions of the following types:

• GiftCardActivate
• GiftCardAddValue
• GiftCardSale
• GiftCardReward

Note: When reversing a transaction, all changes to the account are cancelled, including any additional value added by rewards programs or automated promotions.

Note: If the reversal also fails to return a complete response (likely due to a timeout), wait until connectivity is restored and try again or contact support to ensure the proper result was achieved.

GiftCardReward is used when an account holder makes a payment using a payment form other than a stored value account (e.g. cash or credit card). The account holder may present their stored value account to earn points or other loyalty rewards, which would be added to their account. If successful, the rewarded amount is returned in the response.

Note: This transaction is not used for purchases. Instead, the purchase amount is used to help determine what potential rewards may be added based on the merchant's loyalty and rewards program.

GiftCardSale is used to redeem value from a stored value account.

Note: Partial approvals are supported by default. If the account balance is non-zero but insufficient to cover the full redemption amount, the remaining balance is drained and the amount still owed is returned in the response for additional payment. The merchant may accept any additional tender to cover the amount still owed. If the account holder is unable to provide additional payment and the purchase is cancelled, this transaction should be voided to return the balance back to the account. See the "split tender card amount" and "split tender balance due amount" fields in the response.

GiftCardTip is used to add tip to an existing GiftCardSale. If successful, the tip amount will be subtracted from the stored value account.

Note: This transaction is for future use.

GiftCardVoid is used to cancel a prior successful transaction. When voiding a transaction, all changes to the account are reversed, including any additional value added by rewards programs or automated promotions.

This can be used on prior transactions of the following types:

• GiftCardActivate
• GiftCardAddValue
• GiftCardDeactivate
• GiftCardReplace
• GiftCardSale
• GiftCardReward

Note: Only the most recent transaction is allowed to be referenced as the prior transaction for a gift void. For example, if an activate is run and then an add value is run, only the add value can be voided.

Note: This is for internal use only.

For Canadian merchants, this message can be used to synchronize the keys used for encrypting data in debit card messages for the Canadian debit card network, also referred to as Interac.

Note: This is for internal use only.

Note: This service is used to manage certain Site or Device settings. Please refer to the Developer's Guide for further details.

ManageTokens allows merchants to update information referenced by a specific multi-use token.

Note: Single-use tokens are not supported in this request.

Note: This is for internal use only.

OverrideFraudDecline is used to process a CreditSale, CreditAuth or CreditReturn that was previously declined due to fraud. An override causes the fraud concerns to be ignored. The use of this function on a client should require management approval. This can only be done once, and for the original auth amount.

Note: This is for internal use only.

ParameterDownload is used to initiate an EMV parameter download by clients interfacing to an EMV device. Typically, the client will only download new parameters after receiving an indicator that a download is needed in a prior response message. In addition, the client should time these downloads to be done between batches and during an idle time if possible.

Note: See the PDLNotification indicator in the response header.

PrePaidAddValue is used to increase the balance associated with a prepaid card. The transaction is placed in the current open batch. If a batch is not open, this transaction creates an open batch.

Note: For future use

PrePaidBalanceInquiry returns the available balance for a prepaid card.

RecurringBilling authorizes a one-time or scheduled recurring transaction. The authorization is placed in the current open batch. If a batch is not already open, this transaction creates an open batch.

A scheduled recurring transaction is the default, but a one-time payment can be made by setting the OneTime value to 'Y'. One-time payments may be processed using card data managed by PayPlan. In this case, the stored payment PaymentMethodKey should be provided instead of CardData.

The PayPlan application allows a merchant to set up and schedule recurring payments, but also provides other features including customer information management, secure payment (card and ACH) information storage (card-on-file), and automated email notifications to customers.

RecurringBillingAuth authorizes a one-time or scheduled recurring transaction. These authorization only transactions are not added to the batch to be settled. They can be added to a batch at a later time using CreditAddToBatch. Approved authorizations that have not yet been added to a batch are called open auths.

A scheduled recurring transaction is the default, but a one-time payment can be made by setting the OneTime value to 'Y'. One-time payments may be processed using card data managed by PayPlan. In this case, the stored payment PaymentMethodKey should be provided instead of CardData.

The PayPlan application allows a merchant to set up and schedule recurring payments, but also provides other features including customer information management, secure payment (card and ACH) information storage (card-on-file), and automated email notifications to customers.

ReportActivity returns all activity between the client devices and gateway for a period of time. This can be filtered to a single device if needed.

Note: This has been obsoleted and should no longer be used. See FindTransactions for an alternative.

ReportBatchDetail returns information on each transaction currently associated to the specified batch. This report is for the site and device referenced in the header.

ReportBatchHistory returns information about previous batches over a period of time. This report is for the site referenced in the header.

ReportBatchSummary returns a batch's status information and totals broken down by payment type. This report is for the site and device referenced in the header.

ReportOpenAuths returns all authorizations that have not been added to a batch for settlement. This report is for the site referenced in the header.

ReportSearch returns transaction information for a specified time period.

Note: This has been obsoleted and should no longer be used. See FindTransactions for an alternative.

ReportTxnDetail returns detailed information about a single transaction. This report is for the site and device referenced in the header.

RewardCashQuery is used to query available reward point balance for a participating account. Available for devices in the AP region only

Note: This transaction is for future use.

RewardCashRedeem is used to redeem available reward points for a participating account. Allowed for Reward Cash terminals configured for the Asia Pacific region only.

Note: This transaction is for Future Use.

SendReceipt allows a client to send a receipt from a prior transaction out to specific destinations. The prior transaction must belong to the site and device referenced in the header.

Note: This is for internal use only.

TestCredentials validates the credentials passed in the header, but does not perform an action.

Note: TestCredentials should only be used at the beginning of the certification period to validate credentials and connectivity to the certification environment. This should not be used as a "heartbeat" check and is not required for processing with the gateway.

Tokenize is used to request the gateway to return a multi-use token for the supplied card data. 

No verification of the card data is performed.

Echoed from request

Echoed from request

Echoed from request

Echoed from request

Gateway-generated transaction identifier; can be used in future client requests to uniquely identify this transaction.

Gateway response code that indicates what occurred on the gateway while processing the request.

Note: This does not indicate approval or decline. Clients must see if additional information is provided in the transaction portion of the message from the issuer or other system.

Gateway response message that may provide additional information to the client or user.

Note: In some cases the information may not assist the client or user directly, but it can be provided to a support representative to assist in problem resolution.

Transaction response date and time in the time zone stored for the associated site.

If requested, the multi-use token data generated (or echoed) from the supplied card data.

Echoed from request

Echoed from request

If the transaction was added to a batch, this is the associated batch id.

Note: This field is only returned if the device is configured for this option during the boarding process.

If the transaction was added to a batch, this is the batch's sequence number.

Note: This field is only returned if the device is configured for this option during the boarding process.

Indicates a parameter download is available

Echoed from request

Echoed from request

Hashed card value for customer-specific validation.

FOR INTERNAL USE ONLY