Purchasing Card Level 3 (P-Card L3)
Djust Pay enables Purchasing Card payments with Level 3 itemized data for richer reconciliation and better interchange outcomes. Djust Pay is based on ITS for P-Card L3, but this documentation remains provider-neutral and focuses on your integration with Djust.
Highlights
- CIT flow: PayPage tokenization for cardholder-initiated transactions, then S2S authorization.
- Level 3 at capture: itemized, per-line data is attached to the settlement.
- Split shipments: multiple authorizations and captures are orchestrated safely.
- Zero PAN in your apps: tokenization keeps you out of card data handling.
🧭 What “Level 3” means here
Level 3 adds line-item detail to payment settlement: SKU or commodity codes, unit price and quantity, extended amounts, discounts, freight, duty, and tax breakdowns. Djust Pay validates that all required fields are present before capture to reduce declines and chargebacks.
Typical use cases
- B2B P-Card programs requiring granular controls and rich reporting
- Buyers that reconcile at cost center or project level
- Merchants needing multi-shipment logistics with separate captures
🔁 End-to-end flow
flowchart LR B[Buyer] --> SF[Storefront] SF --> PV[Pre-validation<br>cart and buyer] PV --> CE[Card entry<br>Djust PayPage] CE --> AUTH[Auto authorization<br>Djust backend] AUTH --> LOGI[Logistics<br>split or partials] LOGI --> CAP[Capture with Level 3<br>per shipped lines] CAP --> SETT[Settlement<br>acquirer] SETT --> RPT[Reconciliation] %% ---------- Styles ---------- classDef total fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91; classDef op fill:#e0f7fa,stroke:#06b6d4,stroke-width:2px,color:#065f46; classDef visible fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b; classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827; class B,SF total class PV,CE,AUTH,LOGI,CAP visible class SETT,RPT resp style B rx:8,ry:8 style SF rx:8,ry:8 style PV rx:8,ry:8 style CE rx:8,ry:8 style AUTH rx:8,ry:8 style LOGI rx:8,ry:8 style CAP rx:8,ry:8 style SETT rx:8,ry:8 style RPT rx:8,ry:8
Where key steps happen
- Pre-validation: storefront checks buyer and cart eligibility and prepares the payment context.
- Card entry (PayPage): the buyer enters card details on Djust PayPage (redirect or iFrame); a token is created on successful postback.
- Authorization (CIT, automatic): Djust backend performs the card authorization after a successful PayPage postback.
- Logistics: order is fulfilled in one or more shipments; partials and splits are supported.
- Capture with Level 3: each shipment triggers a capture; Level 3 itemized data is attached per capture after completeness checks.
- Settlement: captured transactions are settled with the acquirer.
- Reconciliation: financial records are matched for reporting and accounting.
- Two prechecks
- Before authorization: call PAY-502 to register or validate required identifiers for the FR market (for example, Market ID and Engagement ID). This must be completed before Djust runs authorization.
- Before capture: Djust performs an internal Level 3 completeness check and blocks the capture if required data is missing or inconsistent.
What changes for integrators
- Card data entry happens on Djust PayPage (redirect or iFrame).
- Authorization is automatic in Djust after a successful PayPage postback - there is no public auth API to call.
- You can manually trigger captures (typically per shipment). Djust attaches Level 3 data at capture time.
- For FR market, captures require Market ID and Engagement ID to be present.
📦 Supported scenarios
- Single shipment: one automatic authorization and one capture with Level 3.
- Partial shipments: one automatic authorization (or additional authorizations if needed), multiple captures — Level 3 data matches shipped lines only.
- Per-shipment authorization at payment time; if holds expire, Djust may re-authorize per configured mode. No incremental top-up above the order amount.
- Cancellations and fails: graceful handling of PayPage dropout and postback errors.
flowchart LR START[Order placed] --> A1[Authorization 1<br>shipment 1 lines] A1 -->|Shipped| C1[Capture 1<br>with L3 lines] A1 -->|Partial| A2[Authorization 2<br>shipment 2 lines] A2 --> C2[Capture 2<br>with L3 lines] C1 --> DONE[Order balanced] C2 --> DONE classDef diff fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00; classDef visible fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b; classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827; class START resp class A1,A2 visible class C1,C2 visible class DONE resp style START rx:8,ry:8 style A1 rx:8,ry:8 style A2 rx:8,ry:8 style C1 rx:8,ry:8 style C2 rx:8,ry:8 style DONE rx:8,ry:8
🧩 What you configure
- PayPage integration: redirect or iFrame; return and dropout URLs; allowed origins.
- Auth mode: agree with Djust which CIT authorization mode is configured for your tenant; authorization is executed automatically by Djust after PayPage postback.
- Front-end must poll the order/payment status after PayPage submission until a terminal status (see Tokenization).
- Level 3 gates: call PAY-502 before authorization for FR; Djust runs a separate pre-capture check automatically.
- Postback handling: handle tokenization outcomes, timeouts, and error mapping into a user-friendly flow.
🔐 Security & compliance
- Tokenize in the PayPage; do not handle raw PAN, expiry, or CVC in your systems.
- Keep PII minimal in postbacks and logs; correlate via opaque tokens.
- Enforce TLS and domain allowlists for redirects, iFrames, and postbacks.
🧭 What’s next
- Prerequisites & Setup - PayPage token, return and dropout URLs, and gating detection
- Authorization modes (CIT) - how Djust Pay runs S2S authorization for P-Cards
- Capture with Level 3 - completeness validation and the field reference
- Errors & postbacks - normalized outcomes and recommended UX
Updated 1 day ago
