Secure funds

All payments processed through the PayHOA platform are routed directly from the payor account to the target account via our payment processor, Stripe. No payments made on the PayHOA platform ever touch a PayHOA bank account, and PayHOA does not have access to any of the funds that are in transit to the target account via Stripe.

This eliminates the risk of litigation, bankruptcy, cyber crime, etc (although very unlikely) from having any affect on funds that belong to the organization. We believe that the aggregation of your funds creates unnecessary risk, so we ensure they are separate from PayHOA throughout the entire process.

Bank account and credit card information

PayHOA does not store any bank account or credit card data in our platform or on our servers. When you input bank account or credit card data, you are actually providing it directly to our payment processor, Stripe. Here is a link about Stripe and their security: https://stripe.com/docs/security/stripe  —  they are a multibillion dollar company and are level 1 PCI compliant.

PayHOA uses a process called tokenization which allows us to use a token to process payments via Stripe on PayHOA, however, this token has zero value outside of PayHOA if someone were to access it. This means that if someone were to hack into your PayHOA account (which is very unlikely), they wouldn’t be able to access any of your bank account or credit card data because it is not anywhere in our site or on our servers. In addition to not storing any sensitive payment data, we scan our servers each quarter for PCI compliance. All servers have received an “A” security rating on the most recent scan.

Access to PayHOA

Our front-facing application authenticates requests with our API via a JWT token. This also verifies origin of requests and denies all tokens from an invalid domain. To add an extra layer of security, we went against the common practice of signing all JWT tokens with the same secret. Instead, each individual user account has its own secret that is used to sign the JWT token. If the case ever arose that someone could figure out the secret key used to sign the JWT they would be limited to that account only.

When an email statement is sent to primary and auxiliary email addresses, it creates a temporary JWT that allows access to the account from that email link. However, the JWT expires after a set period of time and each JWT is unique to each email sent. This temporary JWT provides you access to PayHOA without sharing a username and password with the primary user. This has become common practice in invoicing systems like Freshbooks and PaySimple.

General security

PayHOA software is run completely from within the Amazon AWS environment. We are utilizing EC2 instances to host our API servers, RDS to manage our database instances and we are serving our website through their Cloudfront CDN services. Our complete infrastructure is behind a VPN solution inside of Amazon’s network.

For our application layer itself, we are using best practices in both the frontend application and our core API products. We have full input validation and sanitization occurring within both pieces of the application. This is somewhat redundant; however, it allows us to feel very secure about the input we receive from end users and protect against XSS and CSRF attacks. Our API layer is very strict about the data that we can import. It also fully utilizes the ORM we are using to help limit any exposure to SQLi attacks. The API layer also validates all requests made using standard protocols such as CORS to manage that a client has the proper authority to make requests.

Data redundancy

Our system is redundant at each tier of the application. The CDN provides us with multiple zones spanning the globe, so the system has full failover. PayHOA RDS databases are also setup to be redundant across multiple access zones to ensure that a single outage would not cause any corruption of data. Our database is backed up every 4 hours through incremental snapshots with a full backup occurring nightly.