Payment connector - Introduction

Payment connector - Introduction

Who is this for?

Profile

Role on this topic

Profile

Role on this topic

🔧 System Integrator (SI)

You build and host the connector on behalf of the retailer, or you integrate an existing POS/PSP vendor's API. The "How to develop" guide is your primary reference.

⚙️ Retailer Tech Team

You own an existing PSP or POS integration and want to connect it to OneStock yourself.

🚀 Discovering OneStock

Read the Business Case below to understand when to use the payment hook vs. a standard payment connector.


When your Payment Service Provider (PSP) is not covered by one of our standard payment connectors, you can still fully integrate payments into OneStock OMS using our payment extensibility.

Instead of relying on a pre-built connector, the payment hook allows your teams (or your POS / PSP integration partner) to connect your existing PSP and/or in-store payment flows to OneStock in a flexible and controlled way.

The payment connector covers two distinct use cases:

  • Order In Store payments — generate Pay By Links or direct captures at checkout, surfaced in the OIS interface.

  • Capture and refund for any order, from any sales channel — pass transaction data when creating an order (web, marketplace, OIS, or any other channel) so that OneStock automatically triggers captures and refunds in your connector at the right moment in the order lifecycle: dispatch, cancellation, or return.

This is particularly useful when:

  • You already have a strong relationship with a PSP that we don't currently support as a standard connector.

  • You want to keep using your existing in-store payment infrastructure (POS, card terminals, cashier, etc.) while introducing OneStock OMS.

  • You need OneStock to orchestrate capture and refund operations for web orders without switching PSP or renegotiating contracts.

With the payment hook:

  • OneStock remains the orchestration brain: it manages the order lifecycle, stock, orchestration logic, and triggers payment operations at the right moment.

  • You remain in control of the payment layer: your PSP integration continues to handle authorization, capture, refunds, and reconciliation, while communicating the key payment states back to OneStock through the hook.

  • You avoid re-platforming payments: you can adopt OneStock without changing PSP, POS, or acquiring contracts, reducing project risk and time-to-value.


Business Case Example: Order In Store with POS Payments

Context

A retailer wants to roll out an Order in Store use case:

  • Store associates create an order in OneStock via our Order In Store module

  • The customer pays using the existing point of sale (POS) terminals and PSP already deployed in the store.

  • The retailer does not want to introduce a new online PSP or modify their POS payment setup.

Since our standard payment connectors may not support this in-store PSP, the retailer uses the payment hook to bridge OneStock with their current in-store payment stack.

High-Level Flow

  1. Order creation in store — The store associate creates a customer order in the OneStock Order in Store interface. OneStock calculates the total amount to be paid and prepares the order details.

  2. Payment initiated via POS — Instead of redirecting the customer to an online payment page, the associate uses the existing POS system and payment terminal. The POS communicates with the retailer's current PSP as usual.

  3. Payment hook used to confirm payment to OneStock — Once the payment is confirmed by the POS/PSP, the integration calls the payment hook to confirm the payment result and share key payment references (transaction ID, authorization code, amount, currency, etc.). OneStock updates the order status accordingly.

  4. Order lifecycle managed by OneStock — From this point, OneStock manages sourcing, orchestration, shipment, and status updates.

  5. After-sales operations — If the order is cancelled or partially returned, the retailer triggers the corresponding refund through their existing POS/PSP processes, then uses the payment hook again to inform OneStock of the final payment status.

Business Benefits

  • Faster time-to-market: Deploy Order in Store without waiting for a specific PSP connector.

  • No change to in-store payment processes: Store staff continue using the same POS, terminals, and payment procedures.

  • Lower project risk: Avoids a payment re-platform, which often involves heavy compliance, security, and contractual work.

  • Consistent order visibility: OneStock has a complete view of orders and their payment status, even when payment is processed outside of a standard connector.

  • Future-proof: If you later decide to move to a supported PSP, you can progressively switch from the payment hook to a native connector without redesigning your business flows.


When to Choose the Payment Extensibility

Use the payment hook when:

  • Your PSP is not yet available as a standard connector in our catalog.

  • You want to reuse your existing POS and PSP contracts for omnichannel scenarios such as Order in Store, Ship from Store, or endless aisle.

  • You need OneStock to automatically trigger captures and refunds for web or marketplace orders via your custom connector, in sync with dispatch and return events.

  • You need specific payment behaviours (split payments, local payment methods, complex refund policies) already managed by your internal systems.