Our production environment has just been launched!

Due to our canary deploys, production will have an extra layer of stability to increase uptime and reliability for you.

We practice synthetic canary traffic and promoted deployments based on this synthetic canary traffic passing all test cases. When we do a deployment, we deploy to our dev environment first, and run synthetic canary traffic on all endpoints and testing various scenarios (good password, bad password, good jwt, bad jwt) and have expectations on each scenario - they must either respond with the expected 2xx or 4xx status codes.

If everything passes on dev, then the deployment is promoted to production. 

This is in addition to extensive unit testing we have in each source control repo. As of August 2022, across pay-api, our code coverage is 75%.

Bearer Access Tokens that are issued upon successful auth (the result of a `/token` endpoint call) are now JWTs. The only thing that is stored in the pay-api database related to JWTs are the key ids themselves to check for token expiration (the result of a `/disconnect` endpoint call), which is a fragment of the JWT and not enough itself to make an api call were the database to be compromised. You may read about JWTs here: https://jwt.io/introduction/

pay-api takes your data security and privacy seriously and this change highlights that as much as possible, pay-api is blind to the underlying data.

Amazon:

- mfa (sms + authenticator) supported

- explicit 4xx (invalid username/password/otp code) errors surfaced to the user

Sandbox:

- sandbox mode now supported.

- pass `?sandbox=true` as a Connect query param to go through the sandbox flow and generate a sandbox token

- sandbox uses fake/mocked data. 

Platform:

- `/disconnect` token now deletes data from the pay-api system. Previously it only marked the token as being invalid for use.

Website:

- security page created, explaining our security practices. visit it: https://pay-api.link/security