Signature Capture

What you need to know!

CFXWorks’ designed our payment solution, PaymentCardXpress® (PCX), as an integrated payment and signature capture solution. By integrated we mean that PCX could run both payment (credit and debit card transactions) as well as signature-capture-only transactions. After talking to many merchants we decided to add signature capture to PCX and target merchant environments similar to that illustrated in Figure 1.

Figure 1 – Merchant Environment

The transaction flow we implemented is similar to that illustrated in Figure 1 and is described below:

  1. Sales Person – A sales person initiates the transaction from a PC or thin client. A thin client might be a device capable of only running a browser, a 5250 emulator, a 3270 emulator, or one of the terminal emulators popular in the Linux or UNIX world.
  2. Order Entry Program Request - The sales person uses an order entry program to enter and submit the transaction request to the payment solution PCX.
  3. PCX Response – PCX responds immediately to the order entry program with a unique reference number that is used to identify the transaction request.
  4. PCX Sends Request To Pinpad – PCX sends the request to a pinpad to run either a payment only, a payment and signature capture, or a signature-capture-only transaction request.
  5. Customer Input – Customer enters required card and signature information.
  6. Steps 6 through 8 – Required only for a payment transaction. Note that sensitive card information flows directly from the pinpad to the processor. PCX has no visibility to the sensitive card information enabling PCX to be Out-of-Scope for PCI-DSS.
  1. Pinpad Response – The pinpad responds to PCX.
  2. Response Saved – PCX saves the response to the payment transaction in the audit database, Any signature returned is stored as an image file in the directory identified as the signature repository.
  3. Response To Order Entry Program – Using the reference number returned in step 3, the order entry program can query the audit database for the detailed response to the payment transaction. Using the reference number, the order entry program can also identify, read, and display the signature captured.
  4. Display of Response – Normally, one would display a receipt to the sales person that they would print and hand to the customer. If a signature was captured it would normally be displayed on the receipt. The signature might also be displayed on the order entry device if it has graphics capability.

Our focus from a design and implementation perspective was to create:

  • An Integrated H/W and S/W Solution - One solution supporting payment and signature capture transactions. The same device(pinpad) used for the card transaction and signature capture.
  • Integrated Transaction Capability – The ability to run payment transactions with or without signature capture plus, the ability to run stand alone signature only transactions independent of a payment transaction.
  • Signature Display for Visual Authentication of Signatures – The ability to display signatures for visual authentication.
  • Host Based Control – To centralize control of both payment and signature capture at the host where it can be most easily secured, managed, and supported.
  • Internet/Intranet Connections – A solution with no dependency on serial or USB connections.
  • Host Based Audit Log – To centralized on the host storage of detailed transaction data.
  • Host Based Signature Repository – To create a host-based repository for storing signature images.
  • Real Time – Real time collection, processing, and storage of signatures.
  • Multi-Thread – To implement a multi-thread architecture that supports multiple concurrent transactions to be processed in parallel.

If you think you have a need for signature capture, think about what your answer is to the following questions before making a purchase decision:

Do you need to perform signature capture independent of, integrated with, or both integrated with and independent of your payment solution?

Some merchants want to capture signatures integrated with a payment transaction. Other merchants want to capture signatures independent of any payment card transaction.  Some merchants want both capabilities.

Integrated with a payment transaction: The buyer’s signature is captured from the POS terminal when a “card-present” credit or debit card transaction (SALE, RETURN or AUTH) is used to make a purchase. For example, a customer (customer-present) purchases an item at a retail store and pays using a credit card (card-present). The customer’s signature is captured by the POS device and printed on the receipt.

Independent of a payment transaction – Delivery of merchandise is to be made to a person who is authorized to pick up merchandise but not pay for it. For example, they don’t have cash, check, or a payment card to present. One could describe this as an “on-account” transaction. The signature serves as proof of pickup by the individual making the pickup.

What do you intend to do with the signature once it is captured?

  1. Make no attempt to authenticate the signature.
  2. Display it on a receipt given to the customer.
  3. Save a hard copy of the receipt with the signature displayed on it.
  4. Save an electronic copy of the signature.
  5. Authenticate users by comparing the currently captured signature to a driver’s license presented by the individual doing the pickup.
  6. Authenticate users by comparing the currently captured signature with a hard copy signature that the merchant has on file.
  7. Authenticate users by displaying signatures on a computer display and visually comparing a current signature with an electronic copy of one on file.
  8. Authenticate users by using a computer program to analyze and compare a current signature with an electronic copy of one on file.
  9. Use a captured signature in a legal proceeding.

Comment: To the best of our knowledge there is NO AFFORDABLE software available which can be used to RELIABLY PREDICT that a captured signature is that of a reference signature you have on file!

What type of a device do you intend to use to capture the signature?

For the purpose of the following discussion we will define a pinpad to be an electronic device used to capture, encrypt, and respond to a payment card transaction request.

We define a signature pad to be an electronic device used simply to capture the signature and respond to the request.

These devices very in cost and capability. For example:

  • Devices (signature pads) that only capture signatures.
  • Devices (pinpads) that only run payment transactions for example a SALE or RETURN.
  • Devices (pinpads) that do both of the above.
  • Devices that display the signature as it is being entered.
  • Devices that do not display the signature as it is being entered.

Comment: If you intend to use a pinpad to run payment transactions, it must be certified by your processor and purchased either directly from them or one of their authorized distributors. This is not a CFXWorks’ requirement. It is a PCI-DSS / processor requirement!

On what platform do you intend to run the software used to process the signature? This can be a trick question! Why?

  1. The ability to process a captured signature is primarily a software issue.
  2. Most devices that capture signatures return the signature in a format called 3-byte-ASCII. To be displayed, 3-byte-ASCII files must be converted (processed) to an image format that can be easily displayed.
  3. Some platforms, in particular those that are configured as “headless systems”, cannot convert (process) images. A “headless system” is generally defined as one that lacks the hardware necessary to display images and/or the software required to convert the information read from the capture device to a graphic image that can be displayed. A few examples of headless systems are Linux, Unix, or Windows servers that are specifically configured as headless systems. This is sometimes done for reasons of cost, performance, and/or security. Note that headless systems can store images that have been converted to image
  4. The IBM iSeries (AS/400) is also a headless system. It appears that IBM eliminated from this system the software libraries necessary to convert images. There is not to our knowledge, an IBM supported software alternative that addresses this issue.

On what platform do you intend to run the software used to display the signature?

  1. The ability to display a captured signature once it has been converted to a valid image format, is primarily a hardware issue relating to the device being used for display. The device on which the image is to be displayed must have the ability to display a graphics image.
  2. Using the IBM iSeries as an example, one might use their iSeries on which to store and display previously captured and processed signatures to a web services application deployed on a Windows 10 platform with a graphics display.

How will the above platforms be deployed and maintained?

Integrated with or independent of your payment solution? Over time do you want to have to deploy and maintain one integrated software and terminal solution or two separate software and terminal solutions?

What format/syntax will your signature capture device use when it returns the signature?

If you are doing signature capture only, you might be able to find a signature pad that returns the signature already converted to a valid image file. However, signature pads appear to be almost as expensive as pinpads that are capable of running both payment transactions (including EMV and P2PE) and signature-capture-only transactions.

How will you convert the format/syntax to one that can be displayed on your order entry device?

If you intend to do your own coding and need to convert 3-byte-ASCII text to a valid image format, from a skill standpoint, this can be a very challenging task.

Comment: We suggest that you build a prototype to demonstrate that you can do it successfully before betting the ranch on a successful outcome.

What programming language do you intend to use to convert the format/syntax of the data returned from the capture device to a displayable image?

Same comment as above. We think you will find that converting 3-byte-ASCII text to a valid image format to be near impossible from some high-level programming languages. It may not be even practical.

Comment: We suggest that you build a prototype to demonstrate that you can do it successfully before betting the ranch on a successful outcome.

If your intention is to use the captured signature for authentication purposes, how do you intend to perform authentication?

Most merchants simply attempt to authenticate signatures using visual comparison techniques.

Comment: If you intend to use a captured signature in legal proceeding, check with your legal staff about their requirements relative to capturing, storing, and preserving the integrity of the image. There is likely to be specifics that dramatically impact your choice of hardware and software.