Here is the latest from The Green Sheet magazine on Carpé Charge...

December 14, 2009 • Issue 09:12:01
Name recognition for ISOs
Product: CarpéCharge terminal brandingCompany: CarpéCharge

ISO's operate in relative obscurity. The average person outside the payments realm isn't even likely to know what an ISO is, and some merchants even have a hard time naming their merchant services providers.
A big part of that is due to a lack of visible branding. ISOs sell products, of course, but almost always they are someone else's products, branded exclusively with the manufacturer's logo and phone number.
A new service from CarpéCharge aims to change that. The company recently introduced a free branding service for ISOs that sell CarpéCharge's virtual terminals. The aim is to give the often obscure middleman a little name exposure.
CarpéCharge offers a server-based virtual terminal for merchants. "What we're doing is launching this private-label aspect of it where we can take the terminal as it appears on the screen and give it the custom private label branding for an ISO," said Dean Burke, Director of Marketing and New Business Development for CarpéCharge.
Reinforcing company names
Burke said the service would promote loyalty among merchants by reinforcing the names of their service providers and predisposing them to contact those companies when they have questions or needs. Branding can also help ISOs through merchant-to-merchant referrals; merchants who are aware of their providers are more likely to use the providers' names in conversation.
"What makes the ISO so unique is their service and how they support that merchant," Burke said. "This keeps the branding imagery top of mind, keeps that merchant thinking about who their ISO or merchant service provider is, gives them less opportunity to be distracted by third-party branding and ... helps the ISO streamline their communications with their merchants, so they have a cleaner, more concise look that follows their services."
Burke said ISOs who use the service are consulted to determine exactly how the branding will look, but that the work of creating the logo or image is done by CarpéCharge. ISOs supply finished logos and any instructions on color templates and so forth. Then CarpéCharge takes it from there.
"First and foremost we want to make sure that when the product opens and runs, that their name is very [conspicuous] and their design very clear," Burke said. "Second to that, and supporting it, are the colors and fonts designed around it."
No effect on PCI compliance
CarpéCharge Director of Special Projects Dan Wade added that because the customization work is performed by the terminal supplier, the work has no bearing on Payment Card Industry (PCI) Data Security Standard (DSS) compliance mandates.
"One of the biggest problems when you're wanting to customize something: more often than not you have to do that from a custom software standpoint, meaning you're actually integrating something that's third party and have to go through your [Payment Application DSS] review," Wade said. "This doesn't require that."
CarpéCharge253-857-6411 www.carpecharge.com

Private Label - It's Not Just for the Cool Kids

Don't you just love press releases?
There is a certain mystery to these kinds of things. Like a secret formula with equal parts fluff, BS and smoke, while at the root of it all there lay some form of the truth all done up in her best prom dress. Pardon me as I enter the realm and issue one myself. (And I tried to go real easy on the fluff and BS...but the dress...well).




Carpé Charge Unveils Private Label Product for ISO’s

In direct response to feedback from the ISO reseller marketplace, Carpé Charge now offers their card acceptance software for merchants in private label options specific to the ISO. The skin of the virtual terminal can now take on your own ISO brand, look and feel with multiple customization options. The Carpé Charge brand name and logo is minimized while the ISO brand is prominently featured along with your custom colors and graphics.

“This gives ISO’s the added benefit of strengthening their brand of support and services to their merchants. Instead of having 3rd party branded products pop up all over the place, this new co-branding effort helps keep the lines of communication and support forward between the merchant and their ISO.” Says Dean Burke, Director of Sales and Marketing for Carpé Charge.

Best of all is the price. Customization by our Carpé Charge developers is free of charge for ISO’s who buy their product licenses in bulk. (And Carpé Charge does not take any residuals!)

Call Carpé Charge today and learn how we can increase your market brand equity with a custom private label virtual terminal. And Seize the Charge!

Now what do you do?
Call us at 253-857-6411 and we'll talk shop on how to make it your own.

Integrations - Plaid is the New Pink

Don't bother trying to explain it. Just accept it. Integrations to proecssors in the card payment industry are probably the most complex mess on earth today. In a world where 40 years ago we could launch three men in an air tight cone to the moon on 16K of memory, you'd think things might have advanced a notch or two in our industry...

All my mutternig aside, and I'm happy to report the birth of two new integrations for Carpé Charge..and more on the way.

For the week of Nov. 9th, please get your pens ready to write accounts for:
Chase Paymentech
First Data Nashville

And coming in 10-days-ish...Global.

The rest are in the hopper now and I'll shoot an update skyward as soon as they happen.


In other news...
We've got some very keuhl (aka: cool) things happening by way of custom branded/ private label product. ISO's understand the market value of keeping their wares branded to fit their house. It keeps the message cleaner to the merchant and keeps the headaches down when scanning the list of products.

If you want to talk about private label branding for your ISO...give us a shout.

• Point of Sale Payment Application System Integrators: What is “Out of Scope?”
  
  Before I take off on this one, I have to warn you that because of the nature of various payment applications, this article is targeted solely at our own Carpé Charge product. I say this because in most blogging environments, while there may be a theme or tone that lends itself toward its owner’s biases or products, the course of blatant “marketing” is (IMHO) reserved for other settings. That said, this particular article could not be written in such a manner and due to the stickiness of the topic, had to become more of a “public answer” to a topic that comes up often in our conversations. Whether you’re interest is in our product or not the subject is important none-the-less and can be applied in any conversation within the scope of its context.
  
  
  The rules of the PCI council have been accused of rivaling the clarity of Sanskrit law and thus, most of us in the industry are forced to rely on interpretation of our PCI auditors to help decipher the language. However, it is important to note that interpretation of the rules of play are only as good as their question. Simply stated: ask the wrong question = get the wrong answer.
  
  As elementary as this may sound, please note, the majority of meetings I have within the card payment industry begin with a 10 minute (or longer) volley between my audience and I decoding what it is the other does. Sometimes it can be painfully slow to get a grip on one another’s position in the market. This is not limited to any one industry demographic. I’ve had seasoned pros who thought we were one thing when we were another and vice-versa. So when people start asking questions about PCI rules and codes, my hunch is they are not asking enough questions, the right questions or meeting their responder with a mutual understanding. In the end, the one with the answers is giving an answer to an ill former query.
  
  Case in point: I have run into several companies lately who would have bet their mother and the farm that their company had to go through PCI certifications in order to use an already approved PCI application.
  
  This is not necessarily true.
  
  What I found was that every single time, the company who thought they had to pay the fees for certification were mis-informed because they mis-asked and further more mis-interpreted what they heard.
  
  So here it is. In simple terms, how we work…how we work with you…and what the PCI has to say about it..
  
  
  If you are a POS software developer…
  And you do not have a PCI certified payment application in your software…
  And you want to have one…
  You can integrate to Carpé Charge via our free API…
  And you will be OUT OF SCOPE of PCI-DSS….
  Because…Carpé Charge handles 100% of the transaction. From the moment the card is swiped – through the return of the authorization. And because your system does not touch the data…you are NOT in violation of the code.
  Lastly, our integration to your POS can be completely transparent. What this means to your clients is they will see the look, feel and design of your system as you intended it to be, while our product silently handles 100% of the card payment transaction process.
  

As a POS Developer, VAR or System Integrator - you should be concerned with non certified payment applications and do everything possible to maintain seperation between the POS software and the payment application. A payment applicaiton that removes the POS system from scope is the right way to go.

Just to cover my tracks, below is the mumbo-jumbo straight from PCI. Read it if you like, or refer to the cliff notes above. And remember these words: Our application handles the transaction 100%. Your POS software does not have to touch any credit card transaction data!

________________________________________________________________________
The following excerpt was provided by DRG (Digital Resource Group), a certified PCI auditor and is from the PCI Requirements and Security Assessment Procedures Version 1.2.1 July 2009.

Scope of PA-DSS
The PA-DSS applies to software vendors and others who develop payment applications that store, process, or
transmit cardholder data as part of authorization or settlement, where these payment applications are sold,
distributed, or licensed to third parties.
The following guide can be used to determine whether PA-DSS applies to a given payment application:
Note:
All validated payment
application products must
not be beta versions.
􀂃 PA-DSS does apply to payment applications that are typically sold and installed “off the shelf” without much customization by software
vendors.
􀂃 PA-DSS does apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific
to customer types or functions, or customized per customer request. PA-DSS may only apply to the baseline module if that module is the
only one performing payment functions (once confirmed by a PA-QSA). If other modules also perform payment functions, PA-DSS applies
to those modules as well. Note that it is considered a “best practice” for software vendors to isolate payment functions into a single or
small number of baseline modules, reserving other modules for non-payment functions. This best practice (though not a requirement) can
limit the number of modules subject to PA-DSS.
􀂃 PA-DSS does NOT apply to payment applications offered by application or service providers only as a service (unless such applications
are also sold, licensed, or distributed to third parties) because:
1) The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install,
or control the application or its environment;
2) The application is covered by the application or service provider’s own PCI DSS review (this coverage should be confirmed by the
customer); and/or
3) The application is not sold, distributed, or licensed to third parties.
Examples of these “software as a service” payment applications include:
1) Those offered by Application Service Providers (ASP) who host a payment application on their site for their customers’ use. Note that
PA-DSS would apply, however, if the ASP’s payment application is also sold to, and implemented on, a third-party site, and the
application was not covered by the ASP’s PCI DSS review.
2) Virtual terminal applications that reside on a service providers’ site and are used by merchants to enter their payment transactions.
Note that PA-DSS would apply if the virtual terminal application has a portion that is distributed to, and implemented on, the
merchant’s site, and was not covered by the virtual terminal provider’s PCI DSS review.
􀂃 PA-DSS does NOT apply to non-payment applications that are part of a payment application suite. Such applications (e.g., a fraudmonitoring,
scoring or detection application included in a suite) can be, but are not required to be, covered by PA-DSS if the whole suite is
assessed together. However, if a payment application is part of a suite that relies on PA-DSS requirements being met by controls in other
applications in the suite, a single PA-DSS assessment should be performed for the payment application and all other applications in the
PCI PA-DSS Requirements and Security Assessment Procedures v1.2.1 Page vi
Copyright 2008 PCI Security Standards Council LLC July 2009
suite upon which it relies. These applications should not be assessed separately from other applications they rely upon since all PA-DSS
requirements are not met within a single application.
􀂃 PA-DSS does NOT apply to a payment application developed for and sold to only one customer since this application will be covered as
part of the customer’s normal PCI DSS compliance review. Note that such an application (which may be referred to as a “bespoke”
application) is sold to only one customer (usually a large merchant or service provider), and it is designed and developed according to
customer-provided specifications.
􀂃 PA-DSS does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold,
distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant’s or
service provider’s normal PCI DSS compliance.
For example, for the last two bullets above, whether the in-house developed or “bespoke” payment application stores prohibited sensitive
authentication data or allows complex passwords would be covered as part of the merchant’s or service provider’s normal PCI DSS
compliance efforts and would not require a separate PA-DSS assessment.
The following list, while not all-inclusive, illustrates applications that are NOT payment applications for purposes of PA-DSS (and therefore do not
need to undergo PA-DSS reviews):
􀂃 Operating systems onto which a payment application is installed (for example, Windows, Unix)
􀂃 Database systems that store cardholder data (for example, Oracle)
􀂃 Back-office systems that store cardholder data (for example, for reporting or customer service purposes)
Note:
PCI SSC will ONLY list
applications that are
payment applications.
The scope of the PA-DSS review should include the following:
􀂃 Coverage of all payment application functionality, including but not limited to 1) end-to-end payment functions (authorization and
settlement), 2) input and output, 3) error conditions, 4) interfaces and connections to other files, systems, and/or payment applications or
application components, 5) all cardholder data flows, 6) encryption mechanisms, and 7) authentication mechanisms.
􀂃 Coverage of guidance the payment application vendor is expected to provide to customers and resellers/integrators (see PA-DSS
Implementation Guide later in this document) to ensure 1) customer knows how to implement the payment application in a PCI DSScompliant
manner and 2) customer is clearly told that certain payment application and environment settings may prohibit their PCI DSS
compliance. Note that the payment application vendor may be expected to provide such guidance even when the specific setting 1)
cannot be controlled by the payment application vendor once the application is installed by the customer or 2) is the responsibility of the
customer, not the payment application vendor.
􀂃 Coverage of all selected platforms for the reviewed payment application version (included platforms should be specified)

ISO Hip Hop

Welcome to our new blog. I had previously been testing the idea of using our Facebook account as a medium for driving blogs using their "notes" page and using the "wall" as the vehicle for notification. But I was not entirely satisfied with the results and opted instead to jump in the river with the rest and float in the bigger current. So if this blog looks like it just picked up and started out of no where...well, it sorta did. But not really. Kinda. Anyway. Read on and as the news happens I'll put it here. My ambition is to steer away from the trend and really call out some of the issues I see in regards to our little microchasm in this massive industry of madness.

Onto business...

ISO's...question for you; is your processor looking out for you? Is your processor meeting the needs of the MLS? This is not a loaded question that is about to dive into a marketing pitch. Not entirely anyway. But it leads to this question..."what is the root goal of the processor?"

The answer is: "to secure merchant accounts."

Keep that in mind. "To secure merchant accounts." That little ID number is the gateway to their income. They ride that income like the tide and it is measured directly against the health of the nation's economy. More than any peripheral side plate item on their menu they sell...the pre-transaction based income is their king.

And likewise, it is part of your path to the money as well. Probably the largest part of your income as an ISO.

However, as an ISO you have much to do in order to get that magic little merchant account number. You have to out-serve your opponent. Carry better tools. Be there for them in person, on the phone, on the email...everywhere, all the time. And as an ISO, your part of the food chain is obviously diminished. In other words, your commissions, strong as they may be on residuals, are probably not your only source of income.

Remember the boom of "free terminals?" I'm talking about the free hardware terminals that the processors would "give away" as bait to attract merchants. It's like when banks starting "giving away" free checking accounts or free ATM fees (if you used their bank), etc. etc.

Banks and processors will give away the front door if it means keeping a firm grasp on that merchant account number.

This does not necessarily help the ISO.

Why? How?

Well - for example, as an ISO if you "give away" a terminal (be it a physical terminal or virtual software terminal) then it's obvious that you are not making any money on that terminal. Oh, and by the way - you are going to be expected to service, support, set up and be there for that terminal. The one you did not make any money selling in the first place.

That free terminal was good for the processor, but not so good for you.

So what we see happening is that the 500lb processors are continually building these homogenized meglo-tool-boxes of free lures, baits and services that they in turn expect you to give away to the merchants in order to win their love. But those free tools do not increase the merchant sales...and the processor is not really sharing the micro-increases in costs they are burying into the formula. And at the end of the day, you are losing income for doing the same amount and more of footwork.

As an ISO, your interest is your customer's satisfaction. Look around at the types of tools and resources you have available to you. Look at how they serve the needs of your merchant and look at how they can contribute to the successful profitability of your sales organization.