CreditAdditionalAuth Element

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.

PosCreditAdditionalAuthReqType Complex Type

CreditAdditionalAuth PosCreditAdditionalAuthReqType Complex Type

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.

All

Block1 CreditAdditionalAuthReqBlock1Type Complex Type

Contains a series of required and optional elements

All

GatewayTxnId optional txnIdType Simple Type

Gateway-generated transaction identifier returned in the response of the original transaction.

Amt amtTypeGlobal Simple Type

The amount requested for authorization

AllowDup optional booleanType Simple Type

This is important in cases where the client processes a large number of similar transactions in a very short period of time; sending "Y" will skip duplicate checking on this transaction.

AdditionalTxnFields optional AdditionalTxnFieldsType Complex Type

A common group of optional fields that are supported in several different transaction types for Merchant use

All

Description optional descriptionType Simple Type

Free-form description field. This must not contain sensitive information.

InvoiceNbr optional Restriction of xs:string

Used to log the invoice number on transactions that are not eCommerce.

CustomerID optional customerIDType Simple Type

Used to log Merchant specific customer identification.

Note: For GETI check transactions, this is sent in the CUSTOM3 field.

TxnDescriptor optional TxnDescriptorType Simple Type

Transaction description that is concatenated to a configurable merchant DBA name. The resulting string is sent to the card issuer as the Merchant Name.

Note: Updates to the device are required to utilize this feature. See your Heartland representative for more details.

<xs:element name="CreditAdditionalAuth" type="PosCreditAdditionalAuthReqType" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:annotation>
    <xs:documentation>
      <p xmlns="http://Hps.Exchange.PosGateway">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.</p>
      <p xmlns="http://Hps.Exchange.PosGateway">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.</p>
      <p xmlns="http://Hps.Exchange.PosGateway">
                            The following rules apply:
                            <ul><li>CreditAdditionalAuth is allowed only for restaurant merchants.</li><li>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).</li><li>When the original authorization transaction is fully reversed or voided, any associated CreditAdditionalAuth transactions are reversed.</li><li>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.</li><li>Additional authorizations cannot be voided, edited, or used for returns.</li></ul></p>
      <p xmlns="http://Hps.Exchange.PosGateway">
        <strong>Note:</strong>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).
                          </p>
      <p xmlns="http://Hps.Exchange.PosGateway">
        <strong>Note:</strong>This service has been deprecated. Refer to CreditIncrementalAuth.
                          </p>
    </xs:documentation>
  </xs:annotation>
</xs:element>

Transaction Element | Ver1.0 Element | PosRequest Element | PosGateway Schema