Archive for May, 2025

As we saw in our previous posts Building a Recurring Billing System and Building a Recurring Billing System Part 2: Storing Information, and Building a Recurring Billing System Part 3: Updating the Credit Card we can combine the Authorize.Net ARB API to build a powerful subscription system. In part three we discussed how we would update a customer’s credit card through our own interface. In this part we will create a need to use the functionality discussed in our last post.

The Authorize.Net ARB system allows for us to establish subscriptions that will not expire for up to three years. However, it is possible a customer’s credit card will expire before their subscription is complete. Unfortunately Authorize.Net will not inform us of this until after the credit card has been declined. So our system will need to track expiring credit cards for us.

Fortunately this is easy to do and can be completely automated to boot. In part two we discussed what information we wanted to store. One piece of information we decided to store was the expiration date of the customer’s credit card. This was done specifically so we could keep track of expiring credit cards. How we use it is very straight forward. We will write a cron job that looks for credit cards that within the next 30 days. If we find any we will send those customers an email letting them about the impending expiration of their credit card and invite them to use the page we created in part three to update their credit card information. This is nice because it is all automated!

Sample code this might look like this:


$link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
or die('Could not connect: ' . mysql_error());

mysql_select_db(’my_database’) or die(’Could not select database’);

$query = ‘SELECT * FROM my_table’;

$result = mysql_query($query) or die(’Query failed: ‘ . mysql_error());

while ($row = mysql_fetch_array($result, MYSQL_ASSOC))
{
$to = $row[’email_address’];
$subject = “Update your subscription!”;
$body = “Time to update your subscription.
Go to http://www.domain.com/update.php.”;
mail($to, $subject, $body);
}

mysql_free_result($result);

mysql_close($link);


So far we have created a way for customers to update their subscription and an automated tool to inform them of the expiration of their credit card that invites them to use this tool. Next we will have to deal with the three year limit of the Authorize.Net ARB system.

Technorati Tags: Authorize.Net, payment gateway, recurring billing

As we saw in our previous posts Building a Recurring Billing System and Building a Recurring Billing System Part 2: Storing Information we can combine the Authorize.Net ARB API to build a powerful subscription system. In part two we discussed what information we needed to store to make our system work effectively. Now we will begin to use that information to drive our system.

One issue our system will need to address is the need to change the credit card used in a customer’s subscription. Credit cards expire, are closed, reach their limit or find other reasons where they can not be used either temporarily or permanently. In these cases the customer will want to update the credit card used in the their subscription so it doesn’t go into default.

The concept of how this is pretty straight forward and is a good place for us to start our system. If you remember from part one of Building a Recurring Billing System the Authorize.Net ARB API does offer the ability to change the credit card associated with a subscription. So all we need to do is tell Authorize.Net what subscription to change and what information to replace it with.

So what do we need from our system to make this happen? We will need a web page that will do the following:

• Display the current information associated with the subscription
• Offer the customer an opportunity to provide a new credit card
• Validate the new credit card
• Change the information in the ARB system
• Update our database to reflect this new information

This really is pretty straight forward:

• The customer’s information is easily retrieved from our database
• A basic form will capture the new credit card information
• The code we used when we originally validated the credit card can be used again here
• The ARB system provides a specific API for changing this information so we don’t need to come up with a strategy to complete this task like we will for other tasks our system will offer

Now that we have a system in place for changing a customer’s credit card information, we can expand our system to put this to good use.

Technorati Tags: Authorize.Net, payment gateway, recurring billing

As we saw in our previous post Building a Recurring Billing System, we will need to be responsible for providing a system to effectively manage our customers’ recurring subscriptions. Authorize.Net can take care of the payment processing for us as well as the scheduling of each payment. But to take our level of management and customer service to a higher level we will need to build a system to effectively manage it for us.

To effectively manage this system we will need to store some information pertinent to our transactions. Fortunately we do not need to store sensitive information but it would still be good to point out that being PCI compliant couldn’t hurt.

So what kind of information do we need to store? To determine that we need to know what information Authorize.Net is storing to do our recurring transactions. Any complete recurring billing subscription will store the customer’s credit card information (number and expiration date) and customer’s billing information (name, address, city, state, and zip code). Storing the credit card information is obviously required if the credit card is to be charged again at any point in the future. The billing information is required so Address Verification (AVS) can be done on each transaction (this is only necessary to keep your rates to a minimum. After the first transaction AVS serves no real purpose). Most subscriptions will also contain the customer’s ID number for the website so you can associate the subscription with their record in your system.

The customer billing information can be stored in its entirety as this is not considered sensitive information and you will find no objections from your customers. In fact the odds are your application will require this information anyway. As far as storing the credit card information we do not need to store much. We do not want nor need to store the credit card number. Once it is in the Authorize.Net ARB system we have no use for it. But we will find storing the last four digits handy if we plan to inform our customers of which card they are currently using. Storing the expiration date will be necessary if we plan to inform our customers of their impending expiration and invite them to change it before it does expire.

Do we need to store anything else? Yes. Since the ARB system only allows for subscriptions to be set for a maximum duration of three years, we will need to keep track of how long a customer’s subscription is so as they approach their three year anniversary we can handle the updating of their subscription for another three years. Also, when we initially establish a subscription we will be provided with a subscription ID. We will need to store that if we wish to edit or delete that subscription at a later date.

To summarize, we need to store:

• Last four digits of the customer credit card number
• Expiration date
• Billing address
• Customer ID
• Subscription ID

With this information we have the foundation from which we can build our own subscription system. Now we can begin to offer functionality to our system that will enhance our customer’s user experience and make our job of managing these subscriptions easier.

Technorati Tags: Authorize.Net, payment gateway, recurring billing, PCI DSS CISP

Ever since Authorize.Net released the Automated Recurring Billing API we have had the fortunate experience of integrating quite a few gateways that utilize this new functionality. As we have delved further into the needs of each client it became apparent just how much thought must go into a recurring billing system.

At first glance the ARB API seems to be very sparse in terms of functionality and you would be right. They limit the calls to their system to:

• Creating new ARB subscriptions
• Editing existing subscriptions
• Deleting existing ARB subscriptions

So why is this new API considered so useful? Because those three ARB functions allow us to do everything we need when combined with our own recurring billing system.

So what would our recurring billing system need to do? It would need to:

1. Manage our subscription IDs
2. Track customer credit card expiration dates
3. Notify customers of their credit card’s expiration date
4. Allow customers to change the credit card associated with their subscription
5. Alter the amount of a recurring billing subscription
6. Delete a subscription

Over the next few blog posts we will explore the needs of our recurring billing subscription system and how we will use the Authorize.Net ARB API along with our own subscription tracking system to make a robust subscription application.

From Digital Currency Business E-Gold Indicted for Money Laundering and Illegal Money Transmitting

A federal grand jury in Washington, D.C. has indicted two companies operating a digital currency business and their owners on charges of money laundering, conspiracy, and operating an unlicensed money transmitting business, Assistant Attorney General Alice S. Fisher of the Criminal Division and U.S. Attorney for the District of Columbia Jeffrey A. Taylor announced today.

The four-count indictment, handed down on April 24, 2025 , and unsealed today, charges E‑Gold Ltd; Gold & Silver Reserve, Inc.; and their owners Dr. Douglas L. Jackson, of Satellite Beach, Fla.; Reid A. Jackson, of Melbourne, Fla.; and Barry K. Downey, of Woodbine, Md., each with one count of conspiracy to launder monetary instruments, one count of conspiracy to operate an unlicensed money transmitting business, one count of operating an unlicensed money transmitting business under federal law and one count of money transmission without a license under D.C. law.

Subsequent to the indictment, the Department of Justice also obtained a restraining order on the defendants to prevent the dissipation of assets by the defendants, and 24 seizure warrants on over 58 accounts believed to be property involved in money laundering and operation of an unlicensed money transmitting business. The restraining order does not limit the E‑Gold operation’s ability to use its existing funds to satisfy requests to exchange E-Gold into national currency for customers of non-seized accounts, or its ability to sell precious metals to accomplish the same, once approval has been received.

According to the indictment, E‑Gold’s digital currency, “E‑Gold,” functioned as an alternative payment system and was purportedly backed by stored physical gold. Persons seeking to use the E‑Gold payment system were only required to provide a valid email address to open an E‑Gold account – no other contact information was verified. Once an individual opened an E‑Gold account, he/she could fund the account using any number of exchangers, which converted national currency into E‑Gold. Once open and funded, account holders could access their accounts through the Internet and conduct anonymous transactions with other parties anywhere in the world.

The indictment alleges that E‑Gold has been a highly favored method of payment by operators of investment scams, credit card and identity fraud, and sellers of online child pornography. The indictment alleges that the defendants conducted funds transfers on behalf of their customers, knowing that the funds involved were the proceeds of unlawful activity; namely child exploitation, credit card fraud, and wire (investment) fraud; and thereby violated federal money laundering statutes. The indictment further alleges that the defendants operated the E‑Gold operation without a license in the District of Columbia or any other state, or registering with the federal government, and thereby violated federal and state money transmitting laws. The indictment alleges that this conduct occurred at various times from 1999 through December 2005.

How this indictment will affect the company is unknown. But any merchant currently using E-Gold should consider switching to another processing provider while they sort this out. There is always the possibility they may go bankrupt and/or freeze or hold the funds of their merchants. If this occurs the odds of the merchant getting their money back is very slim.