A build-to-order SAP Business One add-on that authorises,
captures and refunds card payments through your gateway using tokens only — no card numbers stored in SAP. Scoped, quoted and built for your gateway and company database.
Siparişe özel
A build-to-order SAP Business One add-on that authorises, captures and refunds card payments through your gateway using tokens only — no card numbers stored in SAP. Scoped, quoted and built for your gateway and company database. Built to order by ECOSIRE for SAP Business One (build-to-order) — indicative price from $999.00 USD; request a quote for a scoped proposal.
Finance teams running SAP Business One routinely need to take a card payment against a sales order or an A/R invoice. Out of the box there is no safe place to do it. What happens instead is a set of workarounds that every auditor eventually finds: card numbers typed into a UDF on the Business Partner master, expiry dates pasted into the sales order remarks field, a scanned authorisation form filed against the document, or a separate virtual terminal in a browser tab whose receipts are reconciled by hand at month end.
Every one of those workarounds puts primary account number (PAN) data inside the SAP company database, its backups, its transaction log, and any sandbox copy made from it. That drags the entire SAP Business One estate into PCI DSS scope. It also creates a reconciliation problem: the gateway knows a payment happened, SAP does not, and somebody manually creates an Incoming Payment two days later against the wrong invoice.
The fix is well understood — never let the card number reach SAP. Capture it in a hosted field or terminal owned by the gateway, receive a token back, and store only that token. What does not exist is a ready-made add-on that does this for your gateway, your document flow, and your B1 version. That is what ECOSIRE builds.
This is a build-to-order SAP Business One add-on. Nothing is downloaded and nothing is pre-built — after a scoping call and a fixed quotation we develop the add-on against your gateway and your company database, then install it.
Card entry happens in a hosted page or hosted field served by your gateway, launched from the SAP client or from a small companion web form for phone orders. The gateway returns a token, and only the token, the card brand, the last four digits, the expiry month/year and a cardholder reference are written back. Those land in a User-Defined Table (UDT) wrapped in a User-Defined Object (UDO) so the stored credentials get proper SAP object semantics — find/browse forms, authorisations, and removal handled by the object rather than loose SQL. No PAN, no CVV, no track data is ever written to the company database.
The add-on follows the document flow rather than fighting it. On a Sales Order you can run an authorisation for the document total or a nominated amount, with the authorisation reference and expiry stored against the document via User-Defined Fields (UDFs). When the order is copied to a Delivery and then an A/R Invoice, the add-on offers capture of the held authorisation, creates the Incoming Payment through the Service Layer, and applies it against the invoice so the Business Partner balance and the aging report are correct immediately. Partial capture, incremental authorisation and void are handled where the gateway supports them.
A refund is raised against the original captured transaction using the same token, producing an A/R Credit Memo linkage and the corresponding Journal Entry through standard posting rather than manual GL adjustments. Gateway fees, if you want them separated, are posted to a nominated G/L account so the bank reconciliation matches the settlement file rather than the gross amount.
Where the gateway supports stored-credential frameworks, the add-on distinguishes a cardholder-initiated transaction from a merchant-initiated one and sends the correct indicators, so subsequent charges against a saved token are not declined for missing initial-transaction data. That matters for subscription billing, deposits, and back-office charges taken without the customer present.
Approval procedures can be wired so that a charge over a threshold, or a refund of any size, requires a nominated approver before it is sent to the gateway. Every gateway call — request metadata, response code, operator, document, timestamp — is written to an audit UDT that is queryable and reportable. SAP authorisations control who may charge, who may refund and who may delete a stored token.
The add-on is built against the SAP Business One Service Layer (REST/OData) for document and payment creation, and the DI API where a specific operation is better served there. UDFs, UDTs and UDOs carry the token and transaction metadata so the extension survives upgrades cleanly. Gateway credentials live in encrypted configuration outside the company database, not in a UDF. Where you need printed evidence, a Crystal Report layout is supplied for a card receipt showing masked card details and the authorisation reference.
Supported: SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on-premise or cloud-hosted. Delivered per tenant.
Distributors and wholesalers taking deposits on orders; service businesses invoicing cards on completion; any SAP Business One site that has been told by an auditor or an acquiring bank that card data cannot remain in the ERP; and finance teams tired of re-keying gateway settlements into Incoming Payments.
1. Scoping call. We confirm your gateway and the operations it exposes, your B1 version and database platform, which documents need to charge, your approval rules and your G/L mapping. 2. Fixed quotation. You receive a written scope and a fixed price before any development starts. Typical lead time is one working week from acceptance. 3. Build. We develop against a copy of your configuration and test against your gateway's sandbox. 4. Install in test. The add-on is installed into your test company database first, and we run authorisation, capture, partial capture, void and refund with sandbox cards alongside your team. 5. Install in production. After your sign-off we install into the production company database and switch to live gateway credentials. 6. Support window. A support period is included for defect fixes and configuration adjustments; the terms are stated in your quotation.
A short call to confirm the workflow, your platform version and where the integration boundaries sit.
You receive a written scope and a fixed price. Nothing is built until you approve it.
We develop against a copy of your configuration and test it there. Typically two to four weeks.
Sisteminize kurulumu yapar ve kaynak kodunu teslim ederiz; canlıya geçiş sonrası iki hafta destek dahildir. Teslim ettiğimiz koddaki hatalar ücretsiz düzeltilir.
They are accountable for the month-end bank reconciliation and currently match a gateway settlement report against manually keyed Incoming Payments, chasing differences line by line. With capture and refund creating the Incoming Payment and Journal Entry directly in SAP Business One, the settlement file reconciles against posted documents instead of a spreadsheet.
They have been told the SAP company database, its backups and every sandbox copy are in PCI DSS scope because card details sit in UDFs and document remarks. Moving to gateway tokens with an auditable UDT trail removes PAN data from the estate and gives them a defensible answer on who charged what and when.
Their team takes deposits over the phone and today uses a separate virtual terminal, then emails the reference to accounts to key in later. Authorising directly on the Sales Order and capturing at invoicing removes the second system and the re-keying step entirely.
| Kriter | ECOSIRE | Özel Yapı | Rakip | SAP Business One Yerleşik |
|---|---|---|---|---|
| Card token stored instead of PAN in the company database | Dahil | Kısmi destek | Dahil | Dahil değil |
| Authorise on Sales Order and capture at A/R Invoice | Dahil | Kısmi destek | Kısmi destek | Dahil değil |
| Incoming Payment and Journal Entry posted automatically on capture | Dahil | Kısmi destek | Kısmi destek | Dahil değil |
| Refund linked to A/R Credit Memo using the original token | Dahil | Kısmi destek | Kısmi destek | Dahil değil |
| Built for your specific gateway rather than a fixed list | Dahil | Dahil | Dahil değil | Dahil değil |
| Approval procedure gating on charge and refund thresholds | Dahil | Kısmi destek | Kısmi destek | Kısmi destek |
| Queryable audit trail of every gateway request and response | Dahil | Dahil değil | Kısmi destek | Dahil değil |
| Installed into test company database before production | Dahil | Kısmi destek | Kısmi destek | Dahil |
A build-to-order SAP Business One add-on that turns contracts into scheduled A/R Invoices with proration, usage-based charges and deferred revenue schedules. ECOSIRE builds it for your billing rules after a fixed quote.
A build-to-order SAP Business One migration toolkit that maps Tally XML exports — ledgers, groups, stock items, GST masters and open balances — into SAP B1 objects with reconciliation proof. ECOSIRE builds it for your data after a scoping call.
A build-to-order SAP Business One add-on that maps your A/R Invoices and Credit Memos to Peppol PINT AE and exchanges them through your accredited service provider. Scoped, quoted and built for your company database.
A build-to-order SAP Business One add-on that assembles the period VAT return from posted documents, handles reverse charge, validates before filing, and produces your jurisdiction's digital submission and audit file formats.