PayPal Integrations

What PayPal adds to your store's checkout

PayPal works primarily as a wallet: the buyer pays with their account, without typing in their card or address, and PayPal handles authentication. That is why it does not replace the card gateway but sits alongside it as another method, one that carries particular weight with buyers who prefer not to give their card to a store they don't know, and in international sales.

PayPal's pay-later options vary by market: the product, the number of instalments and who is eligible depend on the buyer's country and on PayPal's criteria, not on the store. What the store does control is where pay-later messaging is shown (product page, cart, checkout) and that it matches what the buyer will find when paying.

In terms of data ownership, PayPal owns the buyer's account and the transaction, the store owns the order and the ERP owns the invoice. The shipping address coming from the PayPal account must be validated against the store's logistics rules (zones, carriers, product restrictions) before the order is accepted.

How we connect PayPal to the store

PayPal's current integration is based on its REST APIs and its JavaScript SDK, which displays the payment buttons at checkout and, if desired, on the product page or in the cart for express payment. The order is created in PayPal from the store's server, the buyer approves it in the PayPal window and the store captures it on return. The final status is confirmed via webhooks, not by the browser redirect.

If you prefer to authorise at purchase and charge on shipment, PayPal lets you separate the two steps. The authorisation has a validity period that must be taken into account for orders with long preparation times or made to order, and we handle that in the store's logic.

PayPal is available on Adobe Commerce (Magento), PrestaShop and Shopify, through official modules or native platform support. For custom B2B portals or stores with several legal entities, we build on the API to control which PayPal account each order is charged to.

Disputes, buyer protection and shipment tracking in PayPal

Buyer protection has a flip side for the store: when a customer opens a dispute for an order not received or not as described, PayPal may hold the amount while it is resolved. The best defence is documentation, starting with the shipment tracking number and the carrier.

That is why we send tracking details to PayPal as soon as the ERP or the logistics system creates the shipment. That information helps resolve item-not-received claims and, for accounts with little history, can help make funds available. Disputes reach the store by webhook, which flags the order and alerts customer service so they can respond within the deadline PayPal sets.

Refunds are triggered from the store or the ERP, executed in PayPal via the API and reflected on the order and the credit note, so the buyer gets their money back without needing to open a dispute.

Reconciling PayPal with the ERP

Unlike a bank virtual POS, PayPal does not deposit each payment into your bank: payments build up in the PayPal account balance, from where they are transferred to the bank depending on how the account is set up. From an accounting point of view, the cleanest approach is to treat that balance as a treasury account of its own in the ERP: each payment comes in with its fee, each refund goes out of it and each transfer to the bank is a transfer between accounts.

If you sell in several currencies, the balance can be held in each currency or converted, and that decision affects the accounts, so we agree it with finance from the outset. We automate downloading PayPal's activity and settlement reports and posting them to the ERP (SAP, Microsoft Dynamics 365, Oracle NetSuite, Odoo, Holded, a3ERP or Sage), matching the PayPal transaction ID with the store's order number.