DOTS Order Validation (OV) is a fraud detection service that evaluates customer order information and scores it into a manageable pass/fail/review category. The service allows online merchants the ability to easily weed out fraudulent orders by performing a series of checks and cross checks against the customer's order information.
Developer Guide Map
This section lists the DOTS Order Validation operations and goes into the details behind the inputs and outputs.
OV - OrderValidate (Recommended Operation)
This section shows additional supporting data tables that are associated to the DOTS Order Validation operations.
Similar to the Code and Notes section, this section reflects details on the error outputs that can happen with the service.
Here you'll find code snippets for various programming languages and frameworks along with links to our sample code page on the web site.
This is where you'll go to take the API for a spin. There you can test our recommended operation OV - OrderValidate.
In this section you'll find all the different endpoints supported by this service, input and output schema information as well as an opportunity to try the other endpoints as well.
This is a list of some of the questions we hear more often that you can reference and get answers on right away.
Integrating OV into your application should be easy and straightforward. If you are using a common platform, such as asp, vb, C# .NET, PHP and others, Service Objects may already have sample code built that you can use:
Code Snippets and Sample Code
However, if you are using a common platform that does not already have sample code, you can ask Service Objects to build an example for you. Email email@example.com for more details.
Web Service Structure
Web services provide a standard interface to encapsulate tricky business logic. They allow simple integration of applications via the web. Service Objects has followed web services best practices and come up with some of its own standards to ensure that its web services are as easy to integrate and as accessible as possible.
The host path, or physical location of the web service is here:
The location of the WSDL, or Web Service Definition Language document, is here (This is also accessible via the "Service Definition" link.):
SOAP is done via POST, only with special XML markup in the post-body.
The WSDL is an XML document that defines the interaction web service, meaning its inputs, outputs, operations, and the like. Most likely, you will have another tool read this WSDL and make the operations available to you in your application via some type of proxy class. Whenever your utilities or IDE asks for a WSDL path, you can provide this one. Every web service has operations that it offers to subscribers. These operations, also called methods, contain different functionality and return different outputs.