Private Label Cards

This guide contains information for integrating a private label card with your POS application. We use Synchrony as our third party vendor. See the Getting Started section of the main Fusebox guide for authentication and setting up a test account.

important

The cards and account numbers are specific to each partner. Contact Synchrony for test information that can be linked to your Fusebox account.

Your implementation must address the following business environment criteria specific to the acceptance of Synchrony private label cards: - Uniqueness of the available private label programs. - Acceptance of a private label card as tender. - Requirements negotiated in the agreement between the end user or merchant, and the entity (financial organization) responsible for issuing the cards and providing the processing services.

Transaction Types include:

Your integration should be able to support any of the transaction types listed below:

  • Authorization (Type 01)
  • Sale Forced Purchase (Type 02)
  • Prior Auth (Type 07)
  • Return (Type 09)
  • Transaction Inquiry (Type 22)

note

Forced purchases don’t check the consumer’s available credit line with Synchrony. If the amount of the authorization and the forced purchase don’t match, the forced purchase has no effect on the authorization.

Prior Authorization/Voice Authorization

Send transaction type 07 (Prior Auth) instead of a new type 01 (Authorization) or 02 (Purchase).

A voice authorization can be obtained (if supported) from Synchrony in the event of a “Switch Down” error response or any condition where the POS doesn’t get a response from the host.

note

Synchrony supports both Forced and Voice Authorizations.

Transaction Inquiry

Transaction Inquiry (Type 22) is used to inquire about the status of a transaction.

By tracking our token or unique ID from the original authorization, the transaction inquiry does not require the cardholder’s account number. However, in an error recovery situation, the output response is not returned to the POS. The POS application retains the original transaction details until a successful authorization response is received. Transactions do not communicate to a third party processor and our applications don’t need to reach the host for this transaction to function.

note

We require that your application support the Transaction Inquiry transaction type.

POS Application Input Requests

The input requests are described below.

Terms of Payment

  • Unlike other revolving credit card transactions, the end user or merchant is able to offer various terms on the financing of the purchase. Specific transaction detail information must be presented to ensure that the customer’s account is updated and billed correctly.

Expiration Date

  • A private label card may be issued without an expiration date. In that case, your application must provide one. We require that an expiration date be passed in the input request and recommend using a date no more than 20 years from today.

Physical Characteristics

  • Your POS application must take into account and address the following physical characteristic variances:

  • Magnetic Stripe Data - Information contained on the magnetic stripe of a private label card varies. Private label cards may contain only Track 1, only Track 2, or both Track 1 and Track 2 data.

  • Account Number

    • Private label card account numbers can vary in length and prefix range. They may or may not:
      • Be validated using the MOD-10 routine.
      • Differ between what is embossed on the card and what is on the magnetic stripe.
      • Have BIN ranges that are defined by the private label processor.
      • Be unique for each private label card program.
      • Overlap with other credit cards.

Receipt Considerations

We recommend that you confirm any additional requirements the end-user, merchant, and private label processor may have relating to in-store and down-payment disclosures.