Inside DepositFix we keep data about contacts (name, email, contact id from Stripe) and transactions (date, amount, product name, transaction id from Stripe). This information is kept to help you segment the purchases. Credit card information (number, cvc, exp date) never sent to our servers, we use stripe tokens to charge the cards and they are not stored in our database.
Since we don’t send or store information about the credit cards on our servers, DepositFix doesn’t have to comply with the full PCI spec. However, the whole process is PCI compliant
, because Stripe or PayPal cover most of the requirements. On our side we use SSL encryption everywhere (Browser -> Stripe -> DepositFix -> HubSpot). The database only allows connections from the application itself and blocks everything else.
DepositFix is backed by Amazon AWS
which is proven and secure infrastructure provider:- Amazon RDS (Postgres) as storage- Amazon S3 as CDN for CSS and JS files- CloudFlare as DNS provider- The application is deployed as docker containers with auto recovery mode.
If HubSpot operate with 2 (or more) availability zones, then what about DepositFix?
DepositFix is available in 2 availability zones, if one of the Amazon’s data centers goes down, then we still be able to accept payments from your clients.
How are data backups managed?
Database backups are automatically created every day and kept for 7 days.
What framework/language is used to implement DepositFix?
SSH keys are required to gain console access to our servers and each login is identified by a user. Hosts are segmented and accesses are restricted based on functionality. That is, application requests are allowed only from AWS ELB and database servers can be accessed only from application servers.
We use two-factor authentication to grant access for 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.
What access controls are there around the contact & transaction data does DepositFix store and is the live environment distinct to the dev/staging environment?
Production and test environments are separated and run in different virtual networks.
What structures are in place to prevent ‘leakage’/‘cross-talk’ between their clients data sets? (e.g. altering parameters or inject something that makes me ‘jump’ into another client data-set or any compromised by cookie tweaking)?
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 right for specific objects.
SQL Injection – We use prepared statements for database access to avoid SQL Injection attacks.
Encrypted Data Storage
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.
Vulnerability Scanning & Patching
We periodically check and apply patches for third-party software/services. As and when vulnerabilities are discovered we apply the fixes. We do periodic vulnerability scanning using the services of an authorized QA. Company application is being scanned for vulnerability before each release using snyk.io
Is there a monitoring?
We monitor Stripe and HubSpot APIs on backend, if either of those is down, we show an error message to user before embedding a form. For monitoring of our services we use UptimeRobot