What is a purchasing card?

A purchasing card, often called a p-card or procurement card, is a commercial payment card that an organization assigns to an authorized person, department, or account for approved business purchases. It is typically used within a managed purchasing program that defines who may use the card, which purchases are allowed, what controls apply, and how transactions are reviewed.

The card is the payment tool, while the purchasing-card program is the broader set of people, policies, controls, records, and review steps around it. Card formats, available controls, account structures, reporting fields, and merchant workflows vary by issuer, network, platform, and organization.

Purchasing cards support controlled business buying

Organizations may use purchasing cards for supplies, services, maintenance items, project expenses, or other permitted business purchases. Mastercard describes purchasing cards as tools for business-to-business procurement that can apply parameters to how, where, and when payments are made. Visa describes purchase cards as an alternative to portions of a purchase-order, invoice, and check workflow, with controls that may be assigned by employee, department, or division.

Those descriptions illustrate common uses, not features that every p-card automatically includes. The organization decides the card's intended scope, while the issuer and platform determine which controls and reporting tools are actually available. A buyer should confirm both before relying on a particular workflow.

Assigned authority

The card or account is provided to an approved user or organizational unit for a defined business purpose.

Configured controls

Available limits or restrictions can help express the organization's purchasing rules at the account level.

Transaction records

Receipts, order references, statements, and transaction data support review and reconciliation.

A p-card is not the same as every business card

Commercial cards can serve different purposes. A corporate travel card may focus on employee travel and entertainment, while a purchasing card generally supports procurement or operational buying. Business credit, debit, prepaid, virtual, fleet, and purchasing products can also differ in account ownership, billing, controls, and reporting.

The label printed on a card does not tell a merchant every detail of the buyer's program. A p-card may be physical or represented through another account format, and the buying organization may require internal approval or particular records before or after a transaction. For a broader view of the category, read what commercial cards are.

Readers comparing the card with the surrounding administrative structure can also review how a purchasing-card program works.

Controls and responsibilities come from the program

Depending on the offering, an organization may be able to establish transaction limits, account limits, merchant-category parameters, time-based rules, or department assignments. A control can help guide card use, but it does not replace documented responsibilities, training, approval practices, or transaction review.

GSA SmartPay provides a current, well-documented public-sector example. Its purchase training defines a purchase card or account as a payment solution used for supplies or services procured under official purchase authority. It also distinguishes program coordinators, approving officials, and card or account holders. Private companies, nonprofits, schools, and other organizations may use different roles and terminology, so GSA's structure should be treated as an example rather than a universal rule.

Before issuing or using a card, the buyer should know who may make a purchase, which categories are permitted, what approval is needed, what supporting record belongs with the transaction, who reviews activity, and how exceptions are handled.

What a purchasing-card transaction means for a merchant

For the seller, a purchasing card is a commercial card presented within the buyer's purchasing workflow. The payment interaction may look similar to another card transaction, but the buyer may ask for an invoice number, purchase-order reference, customer code, tax information, or other business detail. The fields a merchant can submit depend on its payment setup and current provider documentation.

A merchant should not promise that a particular terminal, gateway, or data field will satisfy every buyer's program. Instead, it should document its own checkout or invoicing flow, confirm supported fields with its provider, and ask the buyer which business references are needed. The B2B commercial cards FAQ hub and payment processing glossary provide context for related terms.

The merchant does not administer the buyer's internal authority. It accepts the payment through its own configured process while the buyer remains responsible for deciding whether the purchase fits its program.

Records help both sides match the payment

Useful records may include a receipt, invoice, order number, project reference, department code, cardholder name, transaction date, and amount. Which records are needed depends on the buyer's procedures and the merchant's system. Mastercard's current purchasing-card overview describes purchase-order, job-number, and invoice mapping as examples of information used for reconciliation and accounting workflows.

Merchants should collect only information necessary for the transaction and supported business process. General contact forms and ordinary email are not appropriate places for full card numbers, security codes, passwords, bank credentials, complete account numbers, or secret API keys. Sensitive payment details should remain inside the approved payment interface.

Buyers and merchants should also avoid assuming that an enriched data field is present or populated correctly. A short test using non-sensitive business references can reveal whether reports display the information needed for matching.

A practical purchasing-card checklist

Identify the purpose: State which users, departments, purchase types, or operational needs the card is meant to support.
Confirm the offering: Review current issuer and platform documentation for the account format, controls, reports, and support process.
Assign responsibilities: Document who requests, approves, makes, reviews, reconciles, and escalates each transaction.
Define records: Decide which receipts and business references are required and where they will be retained.
Map merchant needs: Confirm what the checkout, invoice, terminal, or gateway can capture without assuming compatibility.
Protect sensitive data: Keep payment credentials out of general forms, email, notes, and shared documents.

Start with the payment workflow

Buyers should begin by documenting the purchases the card will support, the people responsible for each step, and the records needed for review. Merchants should begin with the way p-card customers currently order and pay, then confirm supported business-reference fields with their own payment provider.

For a general discussion of merchant payment options, contact Payments Max. Share business contact information and a high-level workflow description only; do not submit payment credentials or sensitive account data.

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.