Documentation
Start typing to search…
  1. ACCEPT PAYMENTS
  2. Online & In-App Card Payments
  3. Interchange Optimization

B2B Optimizer

Lower B2B interchange by auto‑filling Level 2/3 data across PCE.

The B2B Interchange Optimizer helps merchants qualify for the best possible interchange rates when processing Purchasing and Corporate card transactions.

These card types can accept enhanced transaction data (Level II and Level III), which, when passed accurately, reduces interchange costs. Once enabled, Merchant automatically validates and supplements the required Level II and III data, ensuring merchants always receive optimal rates without any manual input.

Key Features:

  • Automatic Level II & III Optimization: PCE automatically attaches enhanced data to qualifying transactions.
  • No Manual Entry Required: The app runs entirely in the background.
  • Supports Multiple Payment Types: Works with Quick Pay, Invoice, and Recurring Payments.
  • Consistent Savings: Helps merchants qualify for lower interchange categories without changing their existing payment flow.
ℹ️

This feature requires prior enablement and configuration. Please contact the Account Management team to get started.

Once enabled, log in to your Merchant Portal → Apps → find the app → click Activate to start using it.
The feature can also be disabled from the same location.

How it Works

Once activated, PCE automatically identifies Purchasing and Corporate card transactions and adds the required data for Level II and Level III qualification. Processing a sale involves sending the customer's payment details to our API.

  1. Make a POST request to /checkout/v3/payment endpoint with required parameters.

    Refer to Level II/III Data and Address Verification Service (AVS) to know about additional fields that help optimize interchange rates for your transactions.

Parameter

Required

Description

amount

✓

Amount to charge (in USD currency)

cardAccount

✓

Valid Payment Card details or a vaulted token Note: You can vault the card for future use using Card Vaulting guide

merchantId

✓

The Merchant's unique identifier that is used to process the payment.

tenderType

✓

Set to CARD for card transactions.

paymentType

Type of transaction. It is defaulted to Sale

customerName

The name of the customer. Recommended for guest checkout where the card is not vaulted.

posData

An object containing Point of Sale data. While optional, we highly recommend including this object for all keyed (card-not-present/online) transactions to improve approval rates and potentially lower processing fees. You can view more details of the recommended POS data based on presentment type here.

If you have enabled B2B app and you would like the app to generate all the level 3 data for you, you cannot include customerCode along with your invoice and clientReference fields. Doing so will make the system think you are providing your own B2B information in the required B2B fields.

  1. Once the payment request is submitted, our system performs a series of system-level validations before sending the transaction to the card network. These validations check for:
    1. Missing or invalid required fields
    2. Incorrect parameter formats or values
    3. Merchant configuration or permission issues.

    If any validation fails, the request is rejected immediately, and an error response is returned. You must correct the issue and resubmit the request. For a complete list of validation errors and how to resolve them, refer to the System Error Codes guide.
  2. If all system-level validations pass, our system processes the payment and returns a response indicating the outcome. You can learn the outcome of the request via GET /checkout/v3/payment/{id} or wait for the Payment webhook You can determine the result by checking the status and responseCode fields in the response.
    1. status: The primary outcome of the transaction, either APPROVED or DECLINED.
    2. responseCode: A detailed code explaining the reason for the status. See our comprehensive Response code guide guide for full list
  3. For every approved payment, it is critical to store two identifiers
    1. id : The unique Payment ID. Use this for retrieving or voiding the transaction before it settles.
    2. paymentToken: The secure Transaction Token. Use this for follow-up actions like refunds or adjustments after the transaction has settled.

The B2B Optimizer is entirely automated — no manual intervention or data entry is needed for merchants to benefit from lower interchange rates.

If merchants manually enter enhanced data (e.g., tax, invoice number), that information overrides system-generated data.

Merchants must settle batches daily to ensure qualification for the best interchange rates.

Best Practices

  • Downgraded despite B2B optimizer: Check that tax is set correctly, at least one item line exists with qty × unit cost, and destination details are present.
  • Gateway/device limitations: Confirm your gateway and device support full L3; if not, aim for L2.
  • Partial authorizations or edits after settle: Post‑settlement changes don’t re‑qualify prior transactions.

Not all gateways or device integrations support full L3 data sets. Missing or inaccurate fields can cause interchange downgrades.

See Also


Updated 9 days ago