Request Validation Methods

Request validation allows you, as a merchant, to specify the type of action you want to perform. Including a request validation parameter in your Hyp API request clearly indicates your intent.

Since Hyp acts as a bridge between merchants and major payment systems (such as Shva and payment card providers), it is important for each request to clearly state the desired action.

The XML element used to specify the validation method is either <validation> or <mpiValidation>. Read on to learn when to use each.

Supported validation methods

The following are the most commonly used request validation methods (along with the codes they are often referred to as):

• Verify (J5). Places a temporary hold on funds to confirm availability but does not charge yet. Used in the first step of a two-phase commit.

• AutoComm (J4). Finalizes a payment and charges the customer's card. Used for most transactions, including regular payment page transactions, the second step of a two-phase commit, and server-to-server transactions such as recurring payments.

• Token (J102). Converts card details into a secure token for future use. No charge is made. Used in payment flows involving short-term storage.

There are also other methods, but they're not used nearly as often:

• Normal (J2). Performs a simple card validity check. No money is held or charged.

• Dealer (J6). Charges the customer's card and completes the payment in one step, bypassing terminal limits and shifting verification to the credit card company.

• AutoCommHold (J9). Starts a charge but holds it until the merchant confirms final processing with AutoCommRelease.

• AutoCommRelease (J109). Completes a transaction previously initiated with AutoCommHold and sends it for settlement.

There is also a special value, TxnSetup, which instructs Hyp to generate a payment page where the customer can enter card details. The quirk with validation is that you use different XML elements to express your intent depending on whether a payment page is involved.

Validation without a payment page

Consider the following doDeal request, which uses a saved credit card token (cardId) to perform a recurring payment. This payment request is server-to-server, with no payment page involved:

<ashrait>
    <request>
        <version>2000</version>
        <language>ENG</language>
        <command>doDeal</command>
        <doDeal>
            <terminalNumber>{terminalNumber}</terminalNumber>
            <cardId>1092880571131111</cardId>
            <cardExpiration>0328</cardExpiration>
            <total>10000</total>
            <transactionType>Debit</transactionType>
            <creditType>RegularCredit</creditType>
            <currency>ILS</currency>
            <transactionCode>Internet</transactionCode>
            <validation>AutoComm</validation>
        </doDeal>
    </request>
</ashrait>

The request validation method (AutoComm) is specified in the validation element.

Validation in payment page requests

The following is also a doDeal request, but this time it is for a payment page to which the customer will be redirected:

<ashrait>
      <request>
          <version>2000</version>
          <language>ENG</language>
          <command>doDeal</command>
          <doDeal>
              <terminalNumber>{terminalNumber}</terminalNumber>
              <cardNo>CGMPI</cardNo>
              <total>10000</total>
              <transactionType>Debit</transactionType>
              <creditType>RegularCredit</creditType>
              <currency>ILS</currency>
              <transactionCode>Internet</transactionCode>
              <mid>{mid}</mid>
              <uniqueid>837683509-84983498539</uniqueid>
              <validation>TxnSetup</validation>
              <mpiValidation>AutoComm</mpiValidation>
              <successUrl>https://mymerchantwebsite.com/success/</successUrl>
              <errorUrl>https://mymerchantwebsite.com/error/</errorUrl>
          </doDeal>
      </request>
  </ashrait>

Here, the validation element is set to TxnSetup, which tells Hyp to generate a payment page.

However, you still need a way to specify what should happen when the customer fills out their payment details and clicks Pay. Since validation is already set to TxnSetup, you need to use a different element to indicate your intent — this is what mpiValidation is for.

mpiValidation is used instead of validation when requesting a payment page and accepts all the validation methods listed above, except for TxnSetup. In this case, mpiValidation is set to AutoComm.

FAQ

What does MPI stand for?

MPI stands for Merchant Page Interface, the official name for Hyp's payment page server.