Whenever a payment form is submitted, DepositFix saves data about contacts (name, email, contact ID from Stripe) and financial transactions (date, amount, product name, transaction ID from Stripe). This information is stored so it can be synchronized with your HubSpot account. Credit card information (number, CVC, expiration date) are never sent to our servers or to HubSpot. Instead, we use Stripe credit card fields and tokens to charge the cards. In other words, the credit card information never leaves Stripe (or PayPal).
Keeping in mind that we do not send or store credit card information on our servers, DepositFix does not have to comply with the full PCI specification. However, the whole process is PCI compliant, because Stripe and/or PayPal cover those requirements.
On our end, we use SSL encryption everywhere (Browser -> Stripe -> DepositFix -> HubSpot).
The database only allows connections from the application itself and blocks everything else. DepositFix is also backed by Amazon AWS which a is tried and tested secure infrastructure provider.
We use:
- Amazon RDS (Postgres) for storage
- Amazon S3 as ourCDN for CSS and JS files
- CloudFlare as the DNS provider
- Docker containers with auto recovery mode to deploy our application
We do not store sensitive card details on any DepositFix network. Stripe Keys, as well as HubSpot access and refresh tokens are stored in our database in encrypted (AES 256-bit) form.
SSH keys are required to gain console access to our servers and each login is identified by a user. Hosts are segmented and access is restricted based on functionality. Application requests are allowed only from AWS ELB and database servers which can only be accessed from application servers.
We use two-factor authentication (2FA) to grant access to our administrative and infrastructure operations. Administrative privileges are restricted to CTO and lead developer. Additionally, both application level roles and AWS roles are used to ensure only required operations are allowed for specific users.
We periodically check and apply patches to third-party software. We employ the services of an authorized QA for regular vulnerability checks. Our application is also scanned for vulnerability before each release using snyk.io.
The DepositFix Membership Add-on makes parts of your website inaccessible to non-members. Our solution uses a code snippet embedded on your website that redirects non-members to the login page. In practice, that means users will need sign up or log in to access members-only areas. In theory however, a very technical user might figure out how to bypass the code snippet and directly access the members-only pages. In other words, you SHOULD NOT store any confidential or sensitive data on your members-only pages. Our solution was designed as a lightweight content management add-on and not as an enterprise-grade access management solution.
We do not store any of your member data and only serve as an intermediary between the login page and your HubSpot account. Simply put, when someone wants to log in, we will check whether that user exists in HubSpot and then either let them in or ask them to sign up. The only way someone could gain access to the members-only pages is if they had access to an email account that is allowed to log in.
DepositFix operates in 2 availability zones. If one of the Amazon’s data centers goes down, our forms are still able to accept payments.
Database backups are automatically created every day and kept for 7 days.
Backend: Java + SpringBoot + PostgreSQL
Frontend: AngularJs
The production and test environments run separately on different virtual networks.
We use SpringSecurity. It provides protection against attacks like session fixation, clickjacking, cross site request forgery.
All private APIs (used from inside the application) are blocked for cross-domain requests. Also, there are filters checking for access rights for specific objects.
SQL Injection – We use prepared statements for database access to avoid SQL Injection attacks.
We consistently monitor Stripe and HubSpot APIs on the backend. If either of those are down, we show an error message to the user before embedding a form. We use UptimeRobot and Sentry to monitor our services.
