~singpolyma/jmp-pay

ref: e1cb44d0d4156efcd543b661ee937ca876395b7b jmp-pay/config.ru -rw-r--r-- 4.9 KiB
Removed web activation form

No longer used for either registrations or as a hack for payments, everything
handled by ad-hoc commands now and nothing links here any longer.
Merge branch 'rubocop'

* rubocop:
  Update rubocop
Update rubocop

And use settings from sgx-jmp
Expects this to return true
hotfix credit card activation
Copy in account activation logic from sgx-jmp

This is largely duplicated code, but the whole web-activation path should go
away soon.  This fixes web activation to produce the data we actually expect
instead of the hack previously produced.  Instead of an account activation for 5
months, we insert 5 months of balance and then bill for only one month as is reasonable.
Merge branch 'auto-top-up'

* auto-top-up:
  Default auto-top-up to $15 and allow changing from credit card management screen
Default auto-top-up to $15 and allow changing from credit card management screen
Update schema and INSERT to plan_log using new range type

plan_log has been updated to use a range type, so our INSERTs need to be
updated as well.
Allow new users to opt-in to balance auto-top-up

We don't have auto top up built yet, but once we do they will be able to start
getting it right away instead of needing to manually turn it on later.
include sentry when there is a dsn
empty array is not falsy
Do not try query when values is empty

If there are no values to query with, then the SQL will be invalid and throw an
error, so just return empty for that case.
No crash when there are no new transactions to process

Found during initial migration, when a request comes in and it turns out there
are no new transactions, we should not try to set nothing to Redis since that
will throw an exception.
Block users who get too many card declines

If a customer has > 2 card declines in 24 hours or an ip has > 4, then treat all
attempts as declines without looking as an anti-fraud measure.
Prevent double-activate

We're seeing trouble in production where users activate more than once, which
results in suboptimal DB contents.  If they're already active, just redirect
them back to complete registration.
Next