Payment System

Overview / Billing System

We handle payments in a fairly straightforward manner- each customer has a running ledger (jc:billing_history)

PayFlow

Performing a refund

Refunding money via PayFlow must be done manually (simply adding a credit to a ledger will not result in funds going back on a card, it will simply carry forward as a credit towards future charges). To perform a refund, first login: https://manager.paypal.com/

Go to the virtual terminal, choose single transaction, transaction type: Credit

In the original transaction ID field enter the payment ref from the customer's billing information, e.g. ELEP7DF85E73 Credit Card Number should be left blank. After submitting enter the amount to refund, all other fields should be left as is. If the amount is too big (i.e. above the amount we have set for refunds, you'll need to raise that limit in the account settings, then retry the refund).

After the refund is processed, you should enter it as a payment (negative amount) and copy over the transaction ID from the refund, into the customer's payments so we have a record of it. To do this: management -> (customer's page) edit/view sources/pmts -> add payment -> enter amount, date, pnref (unique transaction ID of the refund transaction), result code (0 for success), vendor (PayFlow), leave add to ledger checked (so it will show up in billing history).

Card Data

In the event we ever have to re-enter all credit card data (i.e. moving to a new card processor) we encrypt and store card data for each transaction coming in. Each time card info comes in it is stored in /usr/local/www/scripts/ccard_orders/done/xxxxxx.gpg If the data comes in as the result of a signup, the file name is randomized and must be renamed with the correct customer ID. If the data comes in from the card input page or via the AM, then it will be correctly named with the customer ID. To decrypt the data: (as root):

mail /home/support# gpg --decrypt /usr/local/www/ccard_orders/done/xxxxxx.gpg

Payment-related emails

"No Payment Received for JohnCompanies account - Action Required - WARNING - SHUTDOWN IMMINENT"

(NOTE: this is the 4th notice we have sent in 6 weeks - please respond immediately)


Re:

Hello,

Our records indicate that your billing is not current for your JohnCompanies account -
you may have recently changed billing information or perhaps initiated new service or
altered existing service.

This is not a problem - we simply need you to immediately visit your Account Manager via
this link:

https://secure.johncompanies.com/am/billing.html?cid=col02020

which contains your current and/or past-due charges in detail. Please do contact
payments@johncompanies.com if you have any questions at all.

Thank you so much for your continued business - we appreciate it greatly,

JohnCompanies Hosting

We send out automatic notices to customers who were paying via credit card (have a negative ledger balance) and are marked in the database as in arrears. The send schedule is (subject addendum): week 1
week 3 ("SECOND NOTICE")
week 5 ("THIRD NOTICE - PLEASE RESPOND")
week 6 ("WARNING - SHUTDOWN IMMINENT")
and weekly thereafter

Action to take: Once we see the WARNING - SHUTDOWN IMMINENT notice, we take action to put their server on shutdown in mgmt. We set a cancel date for 10 days in advance and set a note like: "20121024 - no pmt, setup shutdown"

"batch gather report - 5 ($-1720)"

accounts with balances: 50
items added to pfp batch queue: 5 ($-1720)
accounts with alternate (non-ccard) pmt source: 41 ($-16920.06)

Shows you how many accounts have balances (50) how many items were added to the batch and their cumulative value (5, $1720) and the number of accounts and the amount due for customers with no valid payment source (41, $16920.06)

Action to take: Watch that the batch process report - 4 ($1596) email roughly matches what was gathered today. Delete email.

"batch process report - 4 ($1596)"

items processed: 9
items billed successfully: 4 ($1596)
items failed to bill: 5 ($629)

Shows you how many items were in the queue. How many were billed successfully and the total amount (4, $1596), and the items that failed and their value (5, $629)

Action to take:Make sure something was processed today- maybe a payflow error? Delete email.

"failed pfp_batch item for col01788"

RESPMSG:Declined: 15005-This transaction cannot be
processed.;X-VPS-REQUEST-ID:1349989805Scol01788;CVV2MATCH:X;AVSADDR:N;PROCCVV2:I;PROCAVS:
N;HOSTCODE:15005;PNREF:EQFP7B38D1B3;RESULT:12;AVSZIP:N;IAVS:N;

Indicates we have tried to bill this card 5 times and it has failed each time, and now the customer has been placed in arrears (will get automatic email reminders with payment link) and their charge has been removed form the payflow batch queue [https://secure.johncompanies.com/mgmt/pfp_batch.html] In the body of the email you can see details about the reason for failure, usually a decline (as in this example).

Action to take:Make sure it's a standard decline and nothing else wrong. Customer is in arrears, they'll be emailed. Delete email.

"Subscription cancelled for S-1111111111111"

Action to take: See Cancelled PayPal Subs. Delete email.

"successful pmt for col01111"

RESPMSG:Approved;PPREF:0RH20660AL5779445;AUTHCODE:111111;X-VPS-REQUEST-ID:1349524679Scol0
2154;CVV2MATCH:Y;AVSADDR:Y;PROCCVV2:M;PROCAVS:Y;CORRELATIONID:20f200c78b60e;PNREF:ESYP9EC
9E9FF;RESULT:0;AVSZIP:Y;IAVS:N;

This shows that we have a successful payment ('pmt') from this customer. You may search for the payment in PayFlow via the PNREF ID ('ESYP9EC9E9FF'). You can also see some fraud filter results in this email:

CVV2MATCH:Y cvv matches (Y=match, N=no match, X=not supported by bank)

AVSADDR:Y address verification matches (Y=match, N=zip match, X=not supported)

PROCCVV2:M verbose cvv match info (S=not supported, U=unavailable, W=whole zip, X=exact match, Y=yes, Z=zip)

PROCAVS:Y verbose address verification info (M=match, N=no match, P=not processed, S=not supported, U=unavailable, X=no response)

Action to take: Clear arrears for customer. Delete email.

"successful S for 68479f46"

This means a new customer paid via cc. S means we collected $. A means it's only an auth (in the case of a colo) and we will need to collect funds later.

Action to take: rename the cc info file (see New ccard order 68479f46). Delete email

"New ccard order 68479f46"

From: Chad Whitacre
gpg --decrypt /usr/local/www/ccard_orders/done/43b7214f

-----BEGIN PGP MESSAGE-----
Version: Crypt::OpenPGP 1.03

hQEOA/J4/DszoRXaEAQAiNS5gAlrM0XQLMvUnJvq8GWQUptOZvXbIInoCYlWUrMG
ZMLoIuNLua6IlBjV2yJg+r0f8jhsMfsiD+kIZq7xo8sEVfSXaKtGNsi1K8KejUYh
ZKclJh4DULOeTRiumg0rsgbvldgs7JlHa/WfyawJjhD4oV8YJy5c6KyDic4hFmoD
/jmsi60I8bfkgMQ+5SRM8FcMKL4evuheRLvvFbI4f8SoOzR+LsQPsn+hfTsC/Qp8
X2YjCp6w2Oyxz5TZE4SMeVOP70aR1RK7dhr2NQPTr6pFNM3b3zGIgSx8AEs8pgsy
Yv+cVEjV/iUv+lFpBxqqoid53YNTx9pP+kPMjLLKJk6b0sAdAbxG68FtgnBybMui
gMbf92ji+IR87q0D16/nPjzsAv3s7zRw/nzZIOlgQ1/GAFEF7VSyQHzOkd9UQuS0
kU0XXrUpVi0v0PGc9nMWjBA5d2YsaqDrZRxFgzCqwBmhxMHAQqQMzfaEyQIL4EF0
LUpVe4cWiI3aSjPx0aC7bFrioqqXl8vJNfiFMgt1gY6J1PQ4S/wRgmLDNcJrejAA
483biJUsDF4S02JK3QLbUcYN/2NJE2M0/cO88DXXZvm6B7jc0URMN5ytYrv3SYHu
VGuNRCbdaicekD6VnF9EkUA=
=zKlm
-----END PGP MESSAGE-----

This is the encrypted cc info. It's viewable in the email and placed in a file (/usr/local/www/ccard_orders/done/43b7214f) on mail. It needs to be renamed to the customer's final CID:

mv /usr/local/www/ccard_orders/done/43b7214f /usr/local/www/ccard_orders/done/col0NNNN.gpg

This file can be decrypted (gpg --decrypt /path/to/file) to get at the info.

Action to take: rename the file. Delete email.

"failed pmt for col01111"

RESPMSG:Duplicate trans: 10536-The transaction was refused as a result of a duplicate
invoice ID supplied.  Attempt with a new invoice
ID;PNREF:ETHPA078CA93;RESULT:30;X-VPS-REQUEST-ID:1349657543Scol01034;HOSTCODE:10536;

Pretty self explanatory. Their payment failed, and they do know about it. This is sent to us so we know it happened, in case (in the case above) the fault was our own. Most of the time the reason will be a plain old DECLINE.

Action to take: None, unless the fault is our own. The customer should go back to the payment page and try to pay again. Delete email.

"Unknown IPN type:"

payer_email => lenderreviews@gmail.com
first_name => Randall
item_number => 0003
payment_gross => -39.00
mc_currency => USD
receiver_id => 8EKTVPV9MKWF4
ipn_track_id => 15729a938d26a
invoice => a9ca993f
subscr_id => S-5SK10643PA3743414
reason_code => other
business => payments@johncompanies.com
charset => windows-1252
mc_gross => -39.00
custom => type=pp
last_name => Marquis
notify_version => 3.7
payer_id => 9VGJXDXGDW2GC
residence_country => US
mc_fee => -0.74
payer_business_name => Lender Reviews, LLC
txn_id => 0N451285L6563193U
cmd => _notify-validate
verify_sign => AhWl7ACVsSRPc7TyALD6xAJDmOYcAWCn9nISbtkuorhGfhawdKvf6fsV
parent_txn_id => 4SC12038JA710930G
receiver_email => payments@johncompanies.com
item_name => JohnCompanies.com Colocation - $39.00/1 month(s)
payment_status => Reversed
protection_eligibility => Ineligible
payment_date => 12:02:18 Sep 26, 2012 PDT
payment_fee => -0.74
transaction_subject =>
payment_type => instant

Paypal sends us notifications (IPN) for everything that happens with our Paypal account. Most of these IPNs are quietly handled by our billing system. Occasionally, something happens that our billing system doesn't recognize or our billing system wasn't made/meant to handle so it sends this email to let you decide what to do.

Looking through the parameters we see that this was a funds reversal: payment_status => Reversed

You can login to paypal and get more info about this by searching on one of several items:
payer email: lenderreviews@gmail.com
transaction ID: 0N451285L6563193U
subscription ID: S-5SK10643PA3743414

Action to take: customer needs to be re-invoiced and likely the sub was cancelled as well.

Cancelled PayPal Subs

When a customer cancels their sub we will get a notice about it:

From: support@johncompanies.com
To: support@johncompanies.com, dave@johncompanies.com
Subject: Subscription cancelled for S-9X6247331K616642Y

mc_amount1 => 189.00
mc_amount3 => 189.00
payer_email => kpsurplusdotcom@gmail.com
first_name => Ken
item_number => 0003
txn_type => subscr_cancel
mc_currency => USD
payer_status => verified
ipn_track_id => 48ead05d235f3
invoice => 71b20c79
reattempt => 1
subscr_id => S-9X6247331K616642Y
recurring => 1
business => payments@johncompanies.com
charset => windows-1252
custom => type=pp
last_name => Parris
notify_version => 3.7
period1 => 19 D
period3 => 1 M
payer_id => RMV4JADWCFYJW
residence_country => US
amount1 => 189.00
subscr_date => 03:08:14 Oct 09, 2012 PDT
payer_business_name => KP's Surplus
amount3 => 189.00
cmd => _notify-validate
verify_sign => Aoq5NOCTR258UimYDF1inxShI0akA-Ayb5I4ZayCGz8enxz3aUwfLv5c
receiver_email => payments@johncompanies.com
item_name => JohnCompanies.com Colocation - $189.00/1 month(s)

A sub gets canceled for one of a few reasons:

1. the customer took action to cancel it
2. the customer's funding source(s) failed to provide funds to pay the subscription amount
3. paypal sometimes cancels these for their own reasons
4. the sub may have been setup (incorrectly) to make only a certain number of payments, then it auto-cancels

The following is all DEPRECATED. As of 20130301 we now simply refer people to the payments page and they pay whatever their balance due is.

Either way, if we take no action, then the customer will no longer be making payments for their service(s). So we need to take action to get them paying again. To get them paying again via subscription, we send them a payment reminder (invoice).

1. search for the customer in management by the subID (S-9X6247331K616642Y) or payer's email (kpsurplusdotcom@gmail.com)
2. take note of the last payment date for the sub and the nature of the sub payments: how much and how often.
3. click the 're-invoice' link associated with the failed sub, this takes you to the Invoice Generator. It will be pre-filled with some assumptions based on the last payment date and their payment.
4. confirm the payment, start date and interval. The Generator assumes monthly billing in all cases. So if they were paying annually, you will need to correct it. If the sub has been cancelled because paypal was unable to collect funds from their payment sources (most common reason) then the payment due date will have passed. In that case you will see a single amount due now (Single Amount), and the regular (monthly/annual) payment will show up in the 'Recurring Bill' field along with the next regular payment date- it will try to preserve their former monthly payment date. Again, if this is an annual payment it will guess wrong and the values will be incorrect so you must fix them and chose "bill every 12 months" too.
5. in most cases we will allow the Invoice Generator to send out an invoice to the customer, so choose "yes, ..." in the 'Email invoice to customer?' field. The Generator will offer up some stock message formats. In the case of a sub cancelled with a missed payment, it will auto choose "last payment failed" and fill out the body appropriately. In the case of a sub cancelled, but no payment missed, you should make sure the message selected it "sub cxld". Depending on the message, it will prompt you to provide different fields (like "Amt of missed pmt") which it will insert into the message for you. Bottom line- you can write or use whatever message makes sense, just make sure the message includes the link to payment (which is provided just above).
6. select the contacts you want to receive the message- usually just the billing contacts. You may also enter more (comma-delimited)
7. in the 'Notifications' section you notice that support@ is auto-selected to receive notification when the bill is paid. This simply means when the customer pays, the corresponding address will be sent an email indicating the invoice was paid.