Paymentech Orbital SOAP

Chris Lee

unread,

Apr 23, 2008, 3:52:22 PM4/23/08

to

Has anyone succesfully implemented the Chase Paymentech Orbital SOAP
credit card gateway using Delphi, as far as anyone knows?

I have other web services that I am using in other applications, but I
can't get this one to talk. I can see valid XML messages in the
OnBeforeExecute event, and I get an XML response that is fully formed
with a 'Method 'NewOrder' is not implemented' fault message. The XML
content is:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns="urn:ws.paymentech.net/PaymentechGateway">
<SOAP-ENV:Body
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
id="_0">
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring>Method 'NewOrder' not implemented</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

I am assuming that this message is coming back directly from their
server, and not something being generated automatically by Delphi.

They are claiming that they can't see my connections. I can't really
use ProxyTrace to verify the connections because the web service uses
SSL to encrypt all traffic.

I am looking for anyone that has had any success, or any ideas on ways
that I can troubleshoot what is going wrong.

Thanks,
Chris

--

Jean-Marie Babet

unread,

Apr 23, 2008, 5:35:35 PM4/23/08

to

Hello Chris,

I've never used this service but I see that they have a WSDL. I would
propose that we confirm that Delphi is generating a valid request. If you
could catch the OnBeforeExecute data generated by Delphi and post it here
(you can remove the actual data), I'd be happy to investigate.

I'm including couple of examples below. One is what SOAPUI says is a valid
request for NewOrder. The other is from their API documentation.

If the Delphi rquest matches these request (minus optional elements that you
did not specify) then I would probably suggest trying something like their
SDK (there's nothing for Delphi but I think I saw C++, Java, COM and .NET
listed; you can use the COM one from Delphi) but first, if you'd like, let's
validate the XML request.

Cheers,

Bruneau

NEW ORDER SAMPLE (from Web_Services_Specification PDF file)
=================================================

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<NewOrder xmlns="urn:ws.paymentech.net/PaymentechGateway">
<newOrderRequest xsi:type="ns1:NewOrderRequestElement"
xmlns:ns1="urn:ws.paymentech.net/PaymentechGateway" xmlns="">
<ns1:industryType>EC</ns1:industryType>
<ns1:transType>AC</ns1:transType>
<ns1:bin>000001</ns1:bin>
<ns1:merchantID>041756</ns1:merchantID>
<ns1:terminalID>001</ns1:terminalID>
<ns1:ccAccountNum>6011000995500000</ns1:ccAccountNum>
<ns1:ccExp>062008</ns1:ccExp>
<ns1:ccCardVerifyPresenceInd>2</ns1:ccCardVerifyPresenceInd>
<ns1:avsZip>35654</ns1:avsZip>
<ns1:avsAddress1>12345 Daisy Bush Avenue</ns1:avsAddress1>
<ns1:avsAddress2>Apt 18</ns1:avsAddress2>
<ns1:avsCity>Hudson</ns1:avsCity>
<ns1:avsState>FL</ns1:avsState>
<ns1:avsName>Testing</ns1:avsName>
<ns1:avsCountryCode>US</ns1:avsCountryCode>
<ns1:orderID>31103142361483</ns1:orderID>
<ns1:amount>100</ns1:amount>
<ns1:comments>This is a AE AVSCVV AuthCap</ns1:comments>
</newOrderRequest>
</NewOrder>
</soapenv:Body>
</soapenv:Envelope>

SOAPUI Generated
==============
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:pay="urn:ws.paymentech.net/PaymentechGateway">
<soapenv:Header/>
<soapenv:Body>
<pay:NewOrder>
<pay:newOrderRequest>
<pay:industryType>?</pay:industryType>
<pay:transType>?</pay:transType>
<pay:bin>?</pay:bin>
<pay:merchantID>?</pay:merchantID>
<pay:terminalID>?</pay:terminalID>

<pay:cardBrand>?</pay:cardBrand>

<pay:ccAccountNum>?</pay:ccAccountNum>

<pay:ccExp>?</pay:ccExp>

<pay:ccCardVerifyPresenceInd>?</pay:ccCardVerifyPresenceInd>

<pay:ccCardVerifyNum>?</pay:ccCardVerifyNum>

<pay:switchSoloIssueNum>?</pay:switchSoloIssueNum>

<pay:switchSoloCardStartDate>?</pay:switchSoloCardStartDate>

<pay:ecpCheckRT>?</pay:ecpCheckRT>

<pay:ecpCheckDDA>?</pay:ecpCheckDDA>

<pay:ecpBankAcctType>?</pay:ecpBankAcctType>

<pay:ecpAuthMethod>?</pay:ecpAuthMethod>

<pay:ecpDelvMethod>?</pay:ecpDelvMethod>

<pay:avsZip>?</pay:avsZip>

<pay:avsAddress1>?</pay:avsAddress1>

<pay:avsAddress2>?</pay:avsAddress2>

<pay:avsCity>?</pay:avsCity>

<pay:avsState>?</pay:avsState>

<pay:avsName>?</pay:avsName>

<pay:avsCountryCode>?</pay:avsCountryCode>

<pay:avsPhone>?</pay:avsPhone>

<pay:useCustomerRefNum>?</pay:useCustomerRefNum>

<pay:addProfileFromOrder>?</pay:addProfileFromOrder>

<pay:customerRefNum>?</pay:customerRefNum>

<pay:profileOrderOverideInd>?</pay:profileOrderOverideInd>

<pay:authenticationECIInd>?</pay:authenticationECIInd>

<pay:verifyByVisaCAVV>?</pay:verifyByVisaCAVV>

<pay:verifyByVisaXID>?</pay:verifyByVisaXID>

<pay:priorAuthCd>?</pay:priorAuthCd>

<pay:orderID>?</pay:orderID>

<pay:amount>?</pay:amount>

<pay:comments>?</pay:comments>

<pay:shippingRef>?</pay:shippingRef>

<pay:taxInd>?</pay:taxInd>

<pay:taxAmount>?</pay:taxAmount>

<pay:amexTranAdvAddn1>?</pay:amexTranAdvAddn1>

<pay:amexTranAdvAddn2>?</pay:amexTranAdvAddn2>

<pay:amexTranAdvAddn3>?</pay:amexTranAdvAddn3>

<pay:amexTranAdvAddn4>?</pay:amexTranAdvAddn4>

<pay:mcSecureCodeAAV>?</pay:mcSecureCodeAAV>

<pay:softDescMercName>?</pay:softDescMercName>

<pay:softDescProdDesc>?</pay:softDescProdDesc>

<pay:softDescMercCity>?</pay:softDescMercCity>

<pay:softDescMercPhone>?</pay:softDescMercPhone>

<pay:softDescMercURL>?</pay:softDescMercURL>

<pay:softDescMercEmail>?</pay:softDescMercEmail>

<pay:recurringInd>?</pay:recurringInd>

<pay:retryTrace>?</pay:retryTrace>

<pay:pCardOrderID>?</pay:pCardOrderID>

<pay:pCardDestZip>?</pay:pCardDestZip>

<pay:pCardDestName>?</pay:pCardDestName>

<pay:pCardDestAddress>?</pay:pCardDestAddress>

<pay:pCardDestAddress2>?</pay:pCardDestAddress2>

<pay:pCardDestCity>?</pay:pCardDestCity>

<pay:pCardDestStateCd>?</pay:pCardDestStateCd>

<pay:pCard3FreightAmt>?</pay:pCard3FreightAmt>

<pay:pCard3DutyAmt>?</pay:pCard3DutyAmt>

<pay:pCard3DestCountryCd>?</pay:pCard3DestCountryCd>

<pay:pCard3ShipFromZip>?</pay:pCard3ShipFromZip>

<pay:pCard3DiscAmt>?</pay:pCard3DiscAmt>

<pay:pCard3VATtaxAmt>?</pay:pCard3VATtaxAmt>

<pay:pCard3VATtaxRate>?</pay:pCard3VATtaxRate>

<pay:pCard3AltTaxInd>?</pay:pCard3AltTaxInd>

<pay:pCard3AltTaxAmt>?</pay:pCard3AltTaxAmt>

<pay:pCard3LineItemCount>?</pay:pCard3LineItemCount>

<pay:pCard3LineItems>

<pay:item>

<pay:pCard3DtlIndex>?</pay:pCard3DtlIndex>

<pay:pCard3DtlDesc>?</pay:pCard3DtlDesc>

<pay:pCard3DtlProdCd>?</pay:pCard3DtlProdCd>

<pay:pCard3DtlQty>?</pay:pCard3DtlQty>

<pay:pCard3DtlUOM>?</pay:pCard3DtlUOM>

<pay:pCard3DtlTaxAmt>?</pay:pCard3DtlTaxAmt>

<pay:pCard3DtlTaxRate>?</pay:pCard3DtlTaxRate>

<pay:pCard3Dtllinetot>?</pay:pCard3Dtllinetot>

<pay:pCard3DtlDisc>?</pay:pCard3DtlDisc>

<pay:pCard3DtlCommCd>?</pay:pCard3DtlCommCd>

<pay:pCard3DtlUnitCost>?</pay:pCard3DtlUnitCost>

<pay:pCard3DtlGrossNet>?</pay:pCard3DtlGrossNet>

<pay:pCard3DtlTaxType>?</pay:pCard3DtlTaxType>

<pay:pCard3DtlDiscInd>?</pay:pCard3DtlDiscInd>

<pay:pCard3DtlDebitInd>?</pay:pCard3DtlDebitInd>
</pay:item>
</pay:pCard3LineItems>

<pay:magStripeTrack1>?</pay:magStripeTrack1>

<pay:magStripeTrack2>?</pay:magStripeTrack2>

<pay:retailTransInfo>?</pay:retailTransInfo>

<pay:customerName>?</pay:customerName>

<pay:customerEmail>?</pay:customerEmail>

<pay:customerPhone>?</pay:customerPhone>

<pay:cardPresentInd>?</pay:cardPresentInd>

<pay:euddBankSortCode>?</pay:euddBankSortCode>

<pay:euddCountryCode>?</pay:euddCountryCode>

<pay:euddRibCode>?</pay:euddRibCode>

<pay:bmlCustomerIP>?</pay:bmlCustomerIP>

<pay:bmlCustomerEmail>?</pay:bmlCustomerEmail>

<pay:bmlShippingCost>?</pay:bmlShippingCost>

<pay:bmlTNCVersion>?</pay:bmlTNCVersion>

<pay:bmlCustomerRegistrationDate>?</pay:bmlCustomerRegistrationDate>

<pay:bmlCustomerTypeFlag>?</pay:bmlCustomerTypeFlag>

<pay:bmlItemCategory>?</pay:bmlItemCategory>

<pay:bmlPreapprovalInvitationNum>?</pay:bmlPreapprovalInvitationNum>

<pay:bmlMerchantPromotionalCode>?</pay:bmlMerchantPromotionalCode>

<pay:bmlCustomerBirthDate>?</pay:bmlCustomerBirthDate>

<pay:bmlCustomerSSN>?</pay:bmlCustomerSSN>

<pay:bmlCustomerAnnualIncome>?</pay:bmlCustomerAnnualIncome>

<pay:bmlCustomerResidenceStatus>?</pay:bmlCustomerResidenceStatus>

<pay:bmlCustomerCheckingAccount>?</pay:bmlCustomerCheckingAccount>

<pay:bmlCustomerSavingsAccount>?</pay:bmlCustomerSavingsAccount>

<pay:bmlProductDeliveryType>?</pay:bmlProductDeliveryType>

<pay:avsDestName>?</pay:avsDestName>

<pay:avsDestAddress1>?</pay:avsDestAddress1>

<pay:avsDestAddress2>?</pay:avsDestAddress2>

<pay:avsDestCity>?</pay:avsDestCity>

<pay:avsDestState>?</pay:avsDestState>

<pay:avsDestZip>?</pay:avsDestZip>

<pay:avsDestCountryCode>?</pay:avsDestCountryCode>

<pay:avsDestPhoneNum>?</pay:avsDestPhoneNum>

<pay:debitBillerReferenceNumber>?</pay:debitBillerReferenceNumber>
</pay:newOrderRequest>
</pay:NewOrder>
</soapenv:Body>
</soapenv:Envelope>

Chris Lee

unread,

Apr 24, 2008, 11:43:05 AM4/24/08

to

Here is the XML that is going out from the OnBeforeExecute event -- it
does look a little different from their sample but I don't know how
much of it really matters:

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body>
<NewOrder
xmlns="https://ws.paymentech.net/PaymentechGateway/wsdl/PaymentechGatewa
y.wsdl">
<newOrderRequest>
<industryType
xmlns="urn:ws.paymentech.net/PaymentechGateway">EC</industryType>
<transType
xmlns="urn:ws.paymentech.net/PaymentechGateway">A</transType><bin
xmlns="urn:ws.paymentech.net/PaymentechGateway">000002</bin><merchantID
xmlns="urn:ws.paymentech.net/PaymentechGateway">700000000000</merchantID
>
<terminalID
xmlns="urn:ws.paymentech.net/PaymentechGateway">001</terminalID>
<ccAccountNum
xmlns="urn:ws.paymentech.net/PaymentechGateway">5454545454545454</ccAcco
untNum>
<orderID xmlns="urn:ws.paymentech.net/PaymentechGateway">Test WS
Auth</orderID>
<amount
xmlns="urn:ws.paymentech.net/PaymentechGateway">1000</amount></newOrderR
equest>
</NewOrder>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

I was hoping SOAP would be easy to implement for this project, which is
already a SOAP web service all written in Delphi, but I am getting
pretty close to just using COM instead. I have also sent this XML to
them and they don't seem to think there is an issue with it, but I am
not sure the people I have been working with would know.

Thanks,
Chris

Jean-Marie Babet wrote:

--

Chris Lee

unread,

Apr 24, 2008, 2:48:55 PM4/24/08

to

Bruneau,

Thanks for the tip on soapUI -- I had not run across that yet and it is
a handy tool. I find that if I replace the Delphi generated XML with
one from soapUI in the OnBeforeExecute then things work fine -- not
really practical but it does tell me that something is not right in the
importer. The XML that works is:

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:pay="urn:ws.paymentech.net/PaymentechGateway">
<soapenv:Header/>
<soapenv:Body>
<pay:NewOrder>
<pay:newOrderRequest>

<pay:industryType>EC</pay:industryType>
<pay:transType>A</pay:transType>
<pay:bin>000002</pay:bin>
<pay:merchantID>700000000000</pay:merchantID>
<pay:terminalID>001</pay:terminalID>
<pay:ccAccountNum>5454545454545454</pay:ccAccountNum>
<pay:amount>1000</pay:amount>
<pay:orderID>12345</pay:orderID>
<pay:ccExp>200810</pay:ccExp>

</pay:newOrderRequest>
</pay:NewOrder>
</soapenv:Body>
</soapenv:Envelope>

See my previous reply for the XML that doesn't work.

Jean-Marie Babet wrote:

--

Jean-Marie Babet

unread,

Apr 24, 2008, 3:06:10 PM4/24/08

to

Thank you. That's an important piece of information.

Just to make sure: you have the latest runtime/importer available from here:

http://cc.codegear.com/Item/24535

Later today I'll spend some time comparing the XML packets and will relay my
findings.

Cheers,

Bruneau

Chris Lee

unread,

Apr 24, 2008, 3:22:34 PM4/24/08

to

I am using D2007 -- should have specified that earlier, is the runtime
update also applicable for 2007?

Chris

Jean-Marie Babet wrote:

--

Jean-Marie Babet

unread,

Apr 24, 2008, 3:51:45 PM4/24/08

to

Hello,

Just a guess but could you try the following:

Go to the code generated by the importer and locate these lines (towards the
end):

initialization
InvRegistry.RegisterInterface(TypeInfo(PaymentechGatewayPortType),
'https://ws.paymentech.net/PaymentechGateway/wsdl/PaymentechGateway.wsdl',
'UTF-8');

change them to the following:

initialization
InvRegistry.RegisterInterface(TypeInfo(PaymentechGatewayPortType),
'urn:ws.paymentech.net/PaymentechGateway', 'UTF-8');

Basically switch the namespace to "urn:ws.paymentech.net/PaymentechGateway".

Let me know if this helps. If not, I'll dig into the XML snippets.

Cheers,

Bruneau

Jean-Marie Babet

unread,

Apr 24, 2008, 4:09:03 PM4/24/08

to

Hello,

Yes, the runtime update is applicable but might not (don't know for sure) be
relevant in this case. After quickly peeking at the SOAPUI vs Delphi xml you
posted, I suspected a namespace issue. I mentioned that in a follow-up post
with a tweak to the file generated by the importer. Let me know how that
goes and we'll investigate further if necessary.

Cheers,

Bruneau

Chris Lee

unread,

Apr 24, 2008, 4:59:05 PM4/24/08

to

Bruneau,

Yes, changing that line solved the issue. Is this a bug in the importer
to be fixed, or something wrong with the providers WSDL, or just one of
those things to watch for?

I appreciate your help getting this working.

Chris

--

Jean-Marie Babet

unread,

Apr 24, 2008, 6:57:52 PM4/24/08

to

Hello,

Thanks for the follow-up post. Glad things are working better.

The issue is mainly an importer bug that's easy to fix in this case but
needs a runtime overhaul to work in the generic case. I'll try to explain.
Back when SOAP was designed with 'rpc' style in mind you basically had a
method in a namespace with parameters underneath. We tied this method to the
name of the method in the interface and the namespace to the namespace the
interface was registered for. IOW:

The following Delphi code....

PaymentechGatewayPortType = interface(IInvokable)
function NewOrder(const newOrderRequest: NewOrderRequestElement):
NewOrderResponseElement; stdcall;
function MarkForCapture(const markForCaptureRequest:
MarkForCaptureElement): MarkForCaptureResponseElement; stdcall;
function Reversal(const reversalRequest: ReversalElement):
ReversalResponseElement; stdcall;

initialization
InvRegistry.RegisterInterface(TypeInfo(PaymentechGatewayPortType),
'Some-NS', 'UTF-8');

... would translate into:

<env:Body>
<m:MarkForCapture xmlns:m="Some-NS">
...
</m:MarkForCapture>
</env:Body>

... if you invoked 'MarkForCapture(...)'.

Then came document style with literal encoding. In that case, the
"MarkForCapture" element above was no longer the operation (method from a
Delphi point of view) described in the WSDL. It's really a schema type.
However, most implementations kept the operation name and namespace
identical to that of the schema type representing the request. So the API
exposed by Delphi stayed the same. However, then some services started using
a schema element whose name did not match that of the operation. In that
case the importer detects this and switches from an 'rpc' view to a
document/message view. You can see that if you import eBay, for example:

eBayAPIInterface = interface(IInvokable)
['{2BC4B12B-8207-48B3-0A35-5DC99215D445}']

// Cannot unwrap:
// - Input element wrapper name does not match operation's name
// Headers: RequesterCredentials:pInOut
function AddDispute(const AddDisputeRequest: AddDisputeRequest):
AddDisputeResponse; stdcall;

In the case above the schema element is called 'AddDisputeRequest' but the
operation is named 'AddDispute'. The importer realizes that it must expose
the schema request and response types as incoming and return types of the
method.

Now for the case you ran into, the operation name and schema type matched
but *not* their namespaces. This should have triggered the importer to
expose the schema request/response types but that's undesirable because the
programming API exposed has that extra level of indirection. You can force
the importer to take this approach by using the -Ou- option. Here's what it
would generate then:

PaymentechGatewayPortType = interface(IInvokable)
['{C609A42E-2D67-E2A0-C360-3E40FFB0DC1C}']
function NewOrder(const parameters: NewOrder): NewOrderResponse;
stdcall;
function MarkForCapture(const parameters: MarkForCapture):
MarkForCaptureResponse; stdcall;

Now you have an extra level when invoking the method because the 'NewOrder'
type simply contains the NewOrderRequestElement:

//
************************************************************************ //
// XML : NewOrder, global, <element>
// Namespace : urn:ws.paymentech.net/PaymentechGateway
//
************************************************************************ //
NewOrder = class(TRemotable)
private
FnewOrderRequest: NewOrderRequestElement;
public
destructor Destroy; override;
published
property newOrderRequest: NewOrderRequestElement read FnewOrderRequest
write FnewOrderRequest;
end;

This makes it more tedious to code to but it does contain the correct
namespace!!!

Your case though, is one for which there's a nicer workaround. The names of
request types and operations lined up. The namespace didn't and the importer
failed to detect that. But all the request/response types have the *same*
namespace. So we just switch the namespace of the interface to match that of
the request schema elements. And that does the trick. Of course, you can
imagine a scenario where each operation had a request element of identical
name but in a unique namespace. For that case our trick would not work. We
would have had to trigger the importer to expose the extra level
representing each schema type.

I'll add logic to detect your case and have the importer use the correct
namespace. I'll also add logic to detect the case where there are multiple
namespaces. Ultimately though the goal is to have some way to annotate each
method. Then you can store all of that good information along with the
method, you don't ever need that extra level of indirection and the runtime
would have access to everything it needs on a method basis.

Let me know if you need more information!

Cheers,

Bruneau