Yes, exactly the same, in 2008 I used to make half my money in the first 10 days of the month, whereas now it's in the last 10 days. The worst period has always been 11th to 20th, that hasn't changed

hows verotel doing nowadays?

I completely agree with Mitch here. Merchants should have access to both their "hard" declines (card failed authorization) and "soft" declines through a scrubbing filter. Both should have identifiable reason codes for the decline.

Further, being able to tune the scrubbing as part of a mutual goal between Merchant and Provider to minimize risk while maximizing sales is essential. A blanket setting on fraud scrubbing for all Merchant Types is not good customer service.

Every processor scrubs. Scrubbing simply means to verify the information the customer has given. If we did not do this we would have been out of business a long time ago due to credit card fraud. We have been doing this for over 12 years and have gotten very good at it.

Our job is to ensure as many transactions are processed as possible while still keeping the fraud to a minimum. Contrary to what some people think we are not constantly adjusting our scrub or allowing more transactions one day compared to the next. We are in the business of accepting transactions.

If anyone has any questions about our system or why certain declines were issued, all they have to do is ask.

I think this is a great offer and shows that ccbill is a solid open company. I'll take the opportunity then to ask some questions which might help settle some rumors and questions people have.

1. Does the scrub normally vary depending on the active affiliate?
2. Does the scrub normally vary depending on the active sponsor or program?
3. Is pure volume (not merely CB ratio) a normal factor in determining the scrub factor for a transaction?
4. Approximately how often is the scrub factor adjusted per program/affiliate?
5. Are affiliate and program stats shown in normally real time?

It's completely understandable if you can't answer all of these questions in a lot of detail for security reasons. Whatever you can share would be appreciated. :thumbsup

Scrubbing a transaction is typically based on the information the customer provides, along with our proprietary rule sets.

Our transaction scrubs are consistent and rarely change. If we can change something that will allow more throughput with minimal risk, then we will thoroughly test that change on a small beta group, and then possibly expand it out to our entire system. Please remember that our system is optimized to accept as many transactions as possible.

Please see my contact info below if anyone wishes to discuss in further detail. Thanks.

We must remember the economy and the changes to credit cards that happened in 2010. Many consumers, who were used to "going over" and dealing with that later (or charging back) have had to alter their buying behaviors, which is why we see sales later in the month, I think. So the economy is still bouncy, new credit card regs, the fallout from epassports that affects a lot of webmasters and, by extension, cc processors picking up the slack and flucuations should be expected.

As long as the overall tide is rising, so to speak, I'm happy. Ish. LOL! :D

Ccbill has been great for us lately

What happened for those days where your stats where 30% off the norm?

it wasnt that long ago you were saying how bad they are.. what changed?

I wouldnt take your business. It could be just a language issue with how your question is phrased though.
Is intelligence your second language?

Paul:

I'm not sure that "verifying the information the customer has given" completely covers the overall activities of scrubbing, but maybe I'm misunderstanding your definition.

Verification would indicate that you were doing one or more of several checks to verify the validity of the card and the cardholder including:

• Card Number Validation
• AVS - Address Verification w/parameters to handle response
• CVV2/Security Code Check
• IP MisMatch (possibly)

Obviously Customer information verification can and should check the above and integrate them so that, as an example:

AVS is a partial match but the inbound Geo IP is a mismatch, customer is declined.

"Scrubbing" would, in my understanding of the definition, include tracking card history, at least internal to CCBill's systems and scoring the transaction based on the history. CCBill's internal systems would then approve/decline based on this score prior to the transaction being submitted to your processor.

I.E., Customer A has no historic record in CCBill and passes all "verification" checks and is approved by your internal systems and sent to processor.

Customer B has a history with one or more of your Merchants for initiating returns but not in 6 months, passes internal checks.

Customer C has charged back a transaction to one or more of your Merchants in the last 6 months, declined, no transaction passed to processor.

This pre-authorization internal decision is what can be "tuned" either to make the decision making process more or less restrictive, correct?

ah stop... lol you would take anything you could get. :1orglaugh