Windows/ActiveX/soap app, enter cardholder data, swap for eVault token
ActiveX control, entry dialog for cardholder data, on [Submit] use already published soap client functions to submit entries to two different electronic vault services. Designed to relieve merchant apps from being "payment applications" that have to be QSA audited for PA-DSS (a.k.a. PCI) compliance.
Integration of ActiveX control to be activated by any other Windows application. Once active, it is called by that app to pop up a small Windows entry dialog for Card Number, Expiration Date, and Security Code. When user clicks [Submit] button, the COM object makes a soap call to (a) Authorize.net, or (b) Sage Payments to save the cardholder data in their electronic vault. Both of those processors have published soap functions for this purpose. Parse out the search token and other elements returned by the host. Store return values in a transient registry key. COM object returns transient key name to calling app. ActiveX runtime parameters to be set by the calling app, which invokes the COM object and which acts on the returned transient key values.
Our current main app, the app we desire to no longer handle cardholder data, already contains logic to do the card-number-for-GUID swap with Sage Payments. Logic samples can be provided in the Visual DataFlex (VDF) language to demonstrate how that call is made. The ActiveX control we are commissioning would only have to make that one Sage Payments SOAP function call (wsINSERT_CREDIT_CARD_DATA). It returns an XML document. as our VDF app processes it. The soap function returns an object handle. We then use XML parsing logic to isolate the GUID (globally unique i.d.). We have not done that same function yet with Authorize.net; but their CIM service (Customer Information Management) provides a WSDL for that service, and their rep assured me that it can return a unique lookup token that is comparable to a Sage GUID.
Later this week, I will post a more formal set of specifications which includes requirements for runtime parameters such as size and position of the entry dialog, how to retrieve merchant ID and encryption key for the SOAP call, whether to use Sage or Authorize.net. How the call is made and how the return data is parsed and then returned to the invoking application will obviously differ between Sage and Authorize.net. Part of the project will involve conducting the research needed to interface the component with the CIM service.
Skills: sage, management, wsdl, research, .net