xml credit card interface

[Jose Lerebours]

Now this is funny - What in hell makes you believe I have anything to 
prove to you or any of your buddies???

Over the past 15 days alone, I have written at least 10 integrations 
with various Common Carriers around the country, Mexico and Canada ...  
all using SOAP/WSDL, does not matter how heavy the gorilla is or how 
complicated or insufficient the documentation is, this is what the 
industry is using (at least those I do business with) and this is what I 
am using; all of that while developing an AR and AP module for two 
different on line applications.

Here is another fact - if you are doing credit card processing and it is 
not secured, you have fallen through the cracks or your days are counted.

Any respectful merchant will have you go through the certification 
process prior to giving you a live account.  Hence, IT MUST BE SECURED 
prior to it been CERTIFIED ...



On 10/05/2016 03:14 PM, Fairlight via Filepro-list wrote:
> On Wed, Oct 05, 2016 at 02:16:45PM -0400, Jose Lerebours via Filepro-list thus spoke:
>> Yeah, go ahead and tell me again about how much you understand about
>> the things you read on your spare time.  Fact is that if you are
>> processing credit cards on line and XML is involved, there is a
>> greater than 98% chance that SOAP/WSDL is involved.
> In -what- spare time?
>
> Hell, I've -implemented- sending XML files as part of a normal CGI form
> submission.  It's a feature of Fairlight RawQuary because (*drumroll*)
> someone needed to be able to do it in an enterprise environment.  They use
> it 24/7/365.
>
> And 73.6142% of statistics cited on the Internet were pulled out of
> someone's arse.  I surely don't trust -you- to do due diligence and
> actually have a solid number, given that a huge percentage of what you say
> is at least partially off in left field, to put it kindly.
>
>> This is a fact - you do not have to like it - agree with it or even
>> support it ... Just like PHP is used in over 50% of the WWW today.
> If it's a -fact-, provide your source.  Please do.  I want to see this.
>
> You won't, because you can't.  I just tried pulling that statistic from
> Google a few different ways, and it's not happening in any timely fashion.
> The best I've found so far is this:
>
> http://www.bogotobogo.com/WebTechnologies/OpenAPI_RESTful.php
>
> That -still- does not directly address your exact assertion.
>
> No source, zero credibility.  Or, in gamer parlance:  "Screenshot, or it
> didn't happen."  The burden of proof is on you, as you cited a statistic
> which I'm pretty sure doesn't exist at anyone's fingertips.
>
> But source it if you can.  Go ahead, I'll wait.
>
>>> Nothing about accessing the WSDL in a secure fashion guarantees a thing
>>> about the security of the web service itself.  What's more, you're not
>>> processing with them -via the WSDL-.  You're processing with them via the
>>> web service described -by- the WSDL.
>>>
>>> And again...sloppy.
>> My bad - I thought that https meant secured and since it is done
>> using https://~.wsdl I figured that it is a secured WSDL access.
> The WSDL is the description of the service, -not- the service itself.  I've
> integrated with dozens of web services which had a WSDL, which I don't even
> use because I don't use standard SOAP libraries for Perl because they're
> a PITA, and I can do the same mechanical things more quickly and easily
> without invoking a 500lb gorilla.  (SOAP::Lite is an oxymoronically named
> CPAN module, at best.  It's also -horribly- documented.)
>
>> But hey, one never knows.  Perhaps, I keep posting here so that you
>> keep picking apart and so I'll get a free education.
> You're apparently in need of one.  We should start charging you tuition at
> the rate you're going.
>
>> I do not need your approval in any shape or form - For as long as
>> those making the decisions, confirming the certification and signing
>> the checks are happy ...
> Well that's a good thing for you, because you're pretty sure to never
> obtain my approval.
>
> Whatever lets you sleep at night, man.
>
> m->