pay-api takes data security and privacy very seriously
this page provides general information about our data practices to give you confidence in how we secure your data
data center security
- the pay-api api service infrastructure is hosted on Amazon Web Services (AWS)
- the pay-api connect front-end application is hosted on Github Pages, the dev front-end application is hosted on Cloudflare Pages
- we follow AWS best practices which allows us to take advantage from their secured, distributed, fault tolerant environment. to find out more information about AWS security practices, see: https://aws.amazon.com/security
failover and disaster recovery
- our infrastructure and systems use only serverless AWS services, which provide high availability. example of serverless services used in the pay-api architecture: AWS API Gateway, AWS Lambda, AWS DynamoDB
- AWS itself will manage availability within regions for its serverless services
- all of the application service infrastructure, as well as the underlying AWS infrastructure, is codified. in the highly unlikely event that an AWS region is down, due all of the infrastructure being codified, a redeployment to a different region is a simple task
data storage + retention policies
- our intention is to act as the glue between the developer and the provider
- we view data as a liability. we store as little data as possible, and only enough to satisfy the developer’s api requests with as little latency as possible. we have no interest in the content of the data
- we do not sell user data. we only share user data with a single party, the developer, and only user data that the user has explicitly authorized us to share
- we store cookies, usernames, and passwords for valid access tokens, which is how we provide access to providers
- usernames and passwords are captured, encrypted via an AWS KMS symetric key with key rotation enabled, and stored (ciphertext only) in an AWS DynamoDB table (encrypted at rest). The reason we store username and passwords is to increase our service quality; without it, a token would only last two weeks. When storing, we can use it to refresh the cookies, and thus have a token that lasts years.
- our database, AWS DynamoDB, is secured via AWS IAM, and internal systems are provided access via the principal of least privilege
- our encryption key, a Customer Managed Key behind AWS KMS, is secured via AWS IAM, and internal systems are provided access via the principal of least privilege
- our systems use AWS Cloudwatch for logging. our log retention policy is two weeks
- client request and client responses are logged, but username, password, and jwt are redacted from the logs.
- to debug errors that may occur with user configurations we may not have seen before, we may programmatically screenshot errors on a customer account while attempting to fulfill your api request. the screenshots are only generated when an unexpected error occurred, and are only used for debugging said error, and are used for no other purpose. the retention policy on those screenshots is five days. the S3 bucket that temporarily holds this data is encrypted at rest, is not public, and additionally has public access block enabled.
- when a developer calls our /disconnect endpoint, your cookies, username, and password are wiped permanently from our system.
- traffic between you or customers and the pay-api application is encrypted in-transit with TLS
- the database (AWS Dynamo) and related cache stores are encrypted at rest
- usernames and passwords are stored at a hightened level of encryption: they are stored as ciphertext only, encrypted via an AWS KMS Customer Managed Key with key rotation enabled.
- application infrastructure is codified via aws-cdk, and AWS infrastructure is codified via org-formation, and all changes to infrastructure or application source code are done via git
- test coverage for all pay-api source code repositories is 76% as of May 2022
- dependencies are kept up to date automatically with dependabot. additionally, if dependabot detects a vulnerable dependency version via the CVE database with a corresponding library fix, it will automatically resolve the vulnerable version without pay-api intervention
- access to source code is security with two-factor authentication
- we cache aggressively to reduce latencies, but our retention policies on cached data is always less than two weeks. the caches are stored as either AWS DynamoDB tables or as files on AWS S3 depending on cache item size, but either method will store the data encrypted at rest
internal it security
- access to AWS infrastructure, source code, are secured with two-factor authentication. access to third party systems utilize two-factor authentication whenever possible
- we have no employees currently, but if we do, employees will be given the lowest level of access that allows them to get their work done, and employee contracts will include a confidentiality agreement. only authorized employees would have access to our software version control
third party systems
- we use sentry for error alerting. any sensitive payloads sent to sentry are removed of their sensitive or identifiable values before sentry. additionally, we have sentry’s “data scrubbing” feature enabled, which scans and deletes any sensitive data that may have been sent, as well as removes ip addresses detected
- we occassionally use browserless.io and brightdata.com for proxies & residential IP addresses to bypass bot-checks from providers
- when you purchase a paid pay-api client_id, your payment data is not transmitted through nor stored on pay-api systems
- when you purchase a client_id via Gumroad, your payment is processed using PCI Compliant service providers (as of May 2022, are PayPal Connect, Apple Pay, or Google Pay). per Gumroad, your payment details are not stored on nor transmitted via Gumroad’s systems. to find out more about Gumroad’s security information, see: https://customers.gumroad.com/article/189-safe-gumroad-buying
- when purchasing a client_id, you are purchasing a subscription, and are charged monthly
- your email address that you used for the purchase of the client_id is shared with pay-api, to initially set your client name, which we encourage you to email us after purchase to set your preferred application name, which is shown to your customers via Connect
- You may cancel your pay-api and Gumroad subscription at any time by using the link sent to the email address you registered with
- When you are invoiced monthly based on your token usage, we invoice you via Stripe and you are able to pay your invoice via Stripe. Stripe is certified to PCI Service Provider Level 1. to find more about Stripe's security information, see: https://stripe.com/help/security.
- if you have discovered a vulnerability in the pay-api application or services, please contact us at firstname.lastname@example.org
- we review all security concerns brought to our attention, and we take a proactive approach to emerging security issues
If you have any questions, please contact us at email@example.com