~singpolyma/jmp-pay

ref: c1aab035e41147450b7cbe91a2f3d204a906d0ea jmp-pay/config.ru -rw-r--r-- 6.8 KiB
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.
Log plan name on exception to sentry
Allow activating an account via credit card on web

This is designed to work with current jmp-register flows pending new-register
existing.  Link a user to https://pay.jmp.chat/<jid>/activate?return_to=... and
they can choose to buy 5 months of service in either USD or CAD on a supported
credit card.  The card will be vaulted onto their newly-minted customer_id and
the amount immediately billed. No account balance will be set or used, but
rather a plan_log row created starting now and expiring in 5 months.
Initial test suite and helpers
Endpoint that pushes all unknown transactions into Redis

The intent is to use `electrum notify <address> <app>/electrum_noify?address=&customer_id=`

The app asks electrum for all transactions on that address, and then checks
which ones we *don't* already have recorded in the transactions table.  These
are pushed into Redis to be picked up by a to-be-written job that will write
them to the transactions table after 3 confirmations.
Save bidirectional association for customer_id in redis
In production, require customer_id be passed also.

As a security measure, so people can't modify the cards on arbitrary JIDs.
Going to use this as a customer id for the whole billing system

So it's not really braintree specific, even if we make it match the one there.