In order to use the Relay Webservice, applications that normally communicate with the PG must be modified to communicate with the SKLES appliance and use the web service description language (WSDL) described at https://demo4.strongkey.com:8181/strongkeyliteWAR/EncryptionService?wsdl.
The WSDL uses XML data types that are defined in the XML Schema Definition (XSD) at https://demo4.strongkey.com:8181/strongkeyliteWAR/EncryptionService?xsd=1.
There is one service operation – relay – defined in the webservice, which requires seven (7) parameters to perform its task. The seven mandatory parameters are:
TABLE 1: Explanation of Relay Webservice parameters
| # | Parameter | Explanation |
| 1 | did | The unique Encryption Domain identifier. This is a numeric integer that logically represents the context in which your data is encrypted and tokenized. You must specify the DID to ensure the relay service can not only authenticate the request correctly, but also decrypt any tokens before relaying the transaction. |
| 2 | username | The username within the encryption domain that has authorization to call the webservice. At most sites, this is a service credential used by the application communicating with the SKLES appliance. |
| 3 | password | The password of the username within the encryption domain to authenticate the credential of the requester. |
| 4 | relayurl | The URL of the payment gateway that receives transactions. The appliance checks to see if the supplied URL matches - completely or partially - URLs configured and authorized for use by the appliance for relaying transactions. For example, if https://test.authorize.net is configured as an authorized URL for this appliance, supplying the URL https://test.authorize.net/gateway/transact.dll in this parameter will allow the transaction to be relayed to the gateway (assuming all other checks pass). However, https://test.authorize.com/gateway/transact.dll will not. |
| 5 | relayprotocol | The webservice only accepts HTTP or SOAP based relay requests; as such, this parameter must specify either HTTP or SOAP (uppercase) depending on the interface the PG offers. |
| 6 | relayencoding | While future versions of the webservice will support additional encoding schemes, the appliance currently accepts only UTF-8 in this parameter. |
| 7 | relaycontent | This parameter carries XML content that conforms to the schema defined in SKLESRelaySchema.xsd. This schema definition - supplied with the software that implements this service – defines the syntax of the transaction that is translated by the SKLES appliance and relayed to the payment gateway. |
Depending on the type of protocol specified in the relayprotocol parameter, the appliance builds a standard HTTP POST message, or one encapsulating a SOAP request, and posts it to the specified URL. As part of relaying the transaction, the appliance can decrypt any tokens specified in the relaycontent parameter, and substitute decrypted content for the tokens before posting it to the payment gateway's web site.
The appliance waits for a response from the gateway and transmits the response back to the calling application without interpreting the response. All relay transactions are logged in the application server's logs (however, sensitive data is never logged).
Since the Relay Webservice works on standard SOAP over HTTP, any programming environment that supports these two protocols can consume the service. StrongAuth supplies two sample Java clients that show how to consume the service using the HTTP and the SOAP protocols.