Product Documentation

    To minimize the decryption of sensitive PAN data within the application network, SAKA supports a “relay” web service method permitting applications to relay a transaction to a payment gateway (PG). This is accomplished through a Hypertext Transfer Protocol Secure (HTTPS) POST method, or a Simple Object Access Protocol (SOAP) action within an HTTPS POST method.

    The business benefit of using the relay web service is that the application dealing with the PG does not need to decrypt credit card numbers (CCN) before sending transaction to the gateway—SAKA performs this service (functioning like a proxy) on behalf of the application and, thus, reduces or eliminates the need for decrypting CCN. However, to relay transactions, SAKA must have direct network connectivity to the PG's web server, either over the internet or through a virtual private network.

    Here is a sample representation of how an infrastructure might look when configured to use the relay web service to multiple payment gateways:

    In this configuration, the site has the following:

    • A web tier in the demilitarized zone (DMZ) receiving customer transactions from the internet

    • An application tier with servers and databases representing business logic and data

    • A PCI zone containing SAKA

    • Three payment gateways: PG1, which offers both an HTTPS and SOAP interface to the transaction gateway; PG2, which only offers an HTTPS interface; and PG3, which only offers a SOAP interface

    One may connect any number of payment gateways to SAKA as long as the gateways offer standard HTTPS or SOAP interfaces to their services.

    When SAKA receives the request it verifies the credentials presented against its internal database or an optional LDAP directory server and determines their authorization to request the relay service by determining if they are a member of two groups—the RelayAuthorized group and the DecryptionAuthorized group. This is the only service that requires authorized requesters to be part of two groups. This is because the security of the appliance requires that tokens be decrypted and substituted for actual sensitive information and relayed to the payment gateway.

    To use the relay web service, applications that normally communicate with the PG must be modified to communicate with SAKA—which requires seven (7) parameters to perform its task:

    DID

    The unique encryption domain identifier. This is a numeric integer that logically represents the context in which data is encrypted and tokenized. Specify the DID to ensure the relay service can not only authenticate the request correctly, but also decrypt any tokens before relaying the transaction.

    username

    The username within the encryption domain that has authorization to call the web service. At most sites, this is a service credential used by the application communicating with SAKA.

    password

    The password of the username within the encryption domain to authenticate the credential of the requester.

    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.

    relayprotocol

    The web service 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.

    relayencoding

    While future versions of the web service will support additional encoding schemes, the appliance currently accepts only UTF-8 in this parameter.

    relaycontent

    Carries XML content conforming 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 SAKA and relayed to the payment gateway.

    Depending on the type of protocol specified in the relayprotocol parameter, the appliance builds a standard HTTPS 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 tokens specified in the relaycontent parameter and substitute decrypted content for them before posting it to the payment gateway's website.

    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 web service works on standard SOAP over HTTPS, any programming environment that supports these two protocols can consume the service. StrongKey supplies two sample Java clients that show how to consume the service using the HTTPS and the SOAP protocols.