Chasepaymentech Orbital Gateway - Issues with ecommerce in PHP

Question

I have been using Chase Paymentech as an ecommerce gateway for a client. Recently they moved their hosting to GoDaddy and ever since then the ecommerce has not been working. I have tried troubleshooting this with Chase and GoDaddy, but neither end up being much help. I've verified that Chase has the new IP of the GoDaddy hosting server attached to my account.

The reply I get back from Chase tech support is that my requests are never reaching their gateway. Yet I get a XML response back when I try.

$url = "https://orbital1.paymentech.net"; // use for production


$fltGrandTotal = "1.00";
$exp   = "0117"; 
$strCardNumber = "4242424242424242";
$_SESSION[UUID] = '9999555444';

$fltGrandTotal = str_replace(',', '', $fltGrandTotal); 
$total = number_format($fltGrandTotal, 2);
$total2 = str_replace('.', '', $total); 


$post_string="
<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<Request>
<NewOrder>
<IndustryType>EC</IndustryType>
<MessageType>AC</MessageType>
<BIN>000002</BIN>
<MerchantID>XXXXXXX</MerchantID>
<TerminalID>001</TerminalID>
<CardBrand></CardBrand>
<AccountNum>$strCardNumber</AccountNum>
<Exp>$exp</Exp>
<OrderID>$_SESSION[UUID]</OrderID>
<Amount>100</Amount>
<Comments></Comments>
<ShippingRef></ShippingRef>
</NewOrder>
</Request>
";


$header= "POST /authorize/ HTTP/1.0\r\n";       
$header.= "MIME-Version: 1.0\r\n";
$header.= "Content-type: application/PTI43\r\n";
$header.= "Content-length: "  .strlen($post_string) . "\r\n";
$header.= "Content-transfer-encoding: text\r\n";
$header.= "Request-number: 1\r\n";
$header.= "Document-type: Request\r\n";
$header.= "Interface-Version: Test 1.4\r\n";
$header.= "Connection: close \r\n\r\n";                
$header.= $post_string;


$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_TIMEOUT, 20);
curl_setopt($ch, CURLOPT_HEADER, false);                
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, $header);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$data = curl_exec($ch);        
if (curl_errno($ch)) {
 //print curl_error($ch);
} else {
 curl_close($ch);
}



$sitemap = simplexml_load_string($data);

foreach($sitemap as $url) {
    $approval = $url->ApprovalStatus;
    $txRefNum = $url->TxRefNum;
    $message = $url->StatusMsg;
    $authcode = $url->AuthCode;
}

echo "approval: $approval<br>";
echo "txRefNum: $txRefNum<br>";
echo "message: $message<br>";
echo "authcode: $authcode<br>";

The XML that I receive back is:

<?xml version="1.0" encoding="UTF-8"?><Response><QuickResponse HcsTcsInd="T" Version="2">    <ProcStatus>20400</ProcStatus><StatusMsg StatusMsgLth="15">Invalid Request</StatusMsg></QuickResponse></Response>

They've asked me to do things such as setup the same hosting environment as before, with the exact same PHP version, etc. I really can't see why that would have any bearing on things.

Answer 1

Their tech support (hah!) answer is misleading, as a quick response such as this wouldn't even get logged to a system which they could "see."

Orbital responses are intentionally obtuse to mitigate "hacker phishing." To prevent leaking attack vectors, any security issue produces a minimalistic error response. When this happens, and assuming legitimate use is in play, verify at least the following:

• The IP of the server originating the request is statically assigned.
• The IP of the server originating the request is the same as what was used during certification for the merchant ID.
• Your merchant ID is activated and is the same as what was certified.
• The transactions submitted are in the same industry as what was certified.
• Your OrderID is unique. Submitting duplicate OrderID's will fail.
• The XML elements being submitted conform to the PTI version (a.k.a. "Content-Type" above).
• Your Amount includes the implied decimals (the above example would be processed as $1.00 USD since the Amount field contained "100").
• Do not submit optional fields which you do not have content for or which are inapplicable for the transaction (in the above, CardBrand most likely failed the request, though an empty ShippingRef is nonsensical as well).

In short, verify each transaction type you send with the PTI specification document relevant to the XML version number in use. When that document indicates a field as "conditional", then make sure that condition is relevant to your specific transaction being submitted. If a field is documented as "optional" and you don't have anything to give, then don't include it.