security

pay-api takes data security and privacy very seriously

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

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

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

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

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

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

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

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

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
- browserless.io’s privacy policy: https://www.browserless.io/privacy-policy/
- brightdata.com’s privacy policy: https://brightdata.com/privacy

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 security@pay-api.link

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 hello@pay-api.link