The API key, PIN, and random seed will be used to generate an authentication header to be sent along with each REST API request. These keys will never be transmitted or accessible in their raw form.
I included some links describing basic access authentication below, which is what I reviewed before implementing this approach.
Wikipedia - Basic Access Authentication
Here is the official USA ePay documentation on generating the authentication token.
I created a quick C# main method to test out the token creation which you can take a look at below.
Once I have this token, it's just a matter of supplying it in the headers of each request. Here's an example of a CURL statement I used in conjuction with the above snippet to test the token was created correctly:
In order to generate the public API key, I used some documentation found here which details the API spec USA ePay recommends.
This key will be particular to my organization, however it is able to visible publicly, so no need to try and do any subversion or make any extra effort to hide it.
There is an endpoint that can be used to automatically generate this key. The only requirement is the need for the public authentication token, which I mentioned on how to generate above.
The Client JS public key will be used in conjunction with the iFrame USA ePay generates in order to securely communicate with the API on the usaepay.com domain. This key is just appended as a URL parameter in the call to the USA ePay backend inside of the iFrame, without any other real authentication.
There is a Client JS library provided by USA ePay that does all of this "out of the box", however I ended up just building my own since I didn't find the JS library very open and really needed some specific implementation of my own.
The last thing to think about is where I'll store the keys, and how the web client and the API will access them.
Storing them will be through some type of environment variable file or keychain that can persist between builds and service restarts. This part I don't need to put too much thought into at the moment but I have a rough idea.
Like I mentioned earlier, the public API key isn't super secretive, and anything being accessed by a JS app won't be secure in the first place. I plan on having a service running on a web server that will read an environment variable containing the key and then write it out somehow into the DOM, potentially in toa meta tag ensuring nothing can be injected by XSS. My web client can then read this value from the head section of the HTML document and use it as necessary.
The .NET service I will design will also read these from environment variables. The service can then use them to generate the basic authentication token which will live in memory so there's no risk of this being stolen unless the system is compromised.