Swiped Card

Swiped card payments capture data from the magstripe on the back of a card. The reader returns the magstripe data as a string, which your application submits to Priority's Checkout API for authorization. Swipe is the oldest in-person entry method and the least secure of the encrypted-capture options — it uses static track data with no dynamic cryptogram, and is most commonly used as a fallback when EMV chip read fails or when a card has no chip.

📌

Who this is for — ISVs whose deployment captures magstripe data from a supported reader — standalone or integrated with a virtual terminal — and submits it to Priority for authorization.

What Defines a Swipe Transaction

Unlike EMV and NFC, magstripe data is static — the same data is on the card every time. The card network has no dynamic cryptogram to validate against, which is why swipe carries higher fraud risk and higher interchange than EMV or NFC.

When to Use Swipe

If both swipe and EMV are available, always prefer EMV — see EMV Chip.

Required Equipment

How to Submit a Swiped Payment

Endpoint

POST /payment (Checkout API)

Authentication

Basic auth — Base64-encoded username:password in the Authorization header.

Authorization: Basic {base64(username:password)}
Content-Type: application/json

Request body

{
  "merchantId": "4xxx0",
  "tenderType": "Card",
  "amount": "0.01",
  "cardAccount": {
    "magstripe": "%B40xxxxxxxx02060^YOU/A GIFT FOR^23xxxxx00000000000?;4077140007002060=230xxxxxx000000000000000?|0600|CBD4049DD42DA0Axxxxxxxx6A3B293572F568CEFBB7554E09D11D25499DB9xxxxxxxxxxxxxAD74742C569BFDB|F7E12F8E98E49574E3Axxxxxxxxxxxxxxxxx|..."
  }
}

Field reference

Optional: return the full response with echo=true

To receive the complete payment object in the response (instead of issuing a follow-up GET), append echo=true as a URL parameter:

POST /payment?echo=true

Successful response

HTTP 201 Created with the payment object's status set to Approved when the transaction is authorized.

Magstripe Format

The magstripe string returned by a reader is typically composed of:

• Track data — Track 1 and/or Track 2 information from the magstripe
• An encryption block — if the reader uses a secure swipe technology (P2PE) injected with the PPS private key
• Key serial numbers and reader metadata

Different readers may produce slightly different formats. Always submit the string exactly as returned by the reader — Priority's gateway parses the format automatically.

[verify — confirm magstripe string format consistency across all PPS-injected readers used with Priority]

EMV Fallback Behavior

If a chip read fails (damaged chip, read error, terminal issue), most EMV-capable terminals automatically prompt the customer to swipe instead. The resulting transaction is submitted as a standard swipe — there is no special "fallback" field or flag on the API request.

⚠️

Chargeback liability still rests with the merchant for swiped fallback transactions, even on a card that has a working chip. The EMV liability shift only applies to successful chip reads — not to swipes that happen because the chip failed.

Where Magstripe Data Comes From — by Integration Path

Trade-Offs vs Other Entry Methods

Sandbox Testing

Best Practices

Where to Go Next