Inside OnePagePay 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, OnePagePay 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 -> OnePagePay -> HubSpot). The database only allows connections from the application itself and blocks everything else.
OnePagePay 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 OnePagePay?
OnePagePay 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 OnePagePay?
What access controls are there around the contact & transaction data does OnePagePay 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.
There are number of public APIs that allow outside access (actual payment from HubSpot form). The only ID exposed publicly is User ID, but it’s 32-char random String UUID which is hard to brute force. Even if you know the other customer ID all you can do is to submit payment to their account.