Custom build onlyLast verified 2026-09-12 · Reviewed by a person 2026-09-25
There is no Square cartridge for Salesforce B2C Commerce. AppExchange's Commerce Cloud collection doesn't list one, GitHub has no repository for it, and Salesforce Payments runs only on Stripe and PayPal. To take Square payments you have to build and maintain your own cartridge: the Web Payments SDK tokenizes the card in the browser, and your server-side code sends that token to Square's Payments API.1
UAT-Ops testing: Square's sandbox was verified by UAT-Ops on 2026-09-11 with the directory's card flow (6 passed) → evidence on the Square hub. The Salesforce Commerce Cloud (B2C) integration itself has not been run.
Sources checked: 15 claims from 6 sites, listed at the foot of the page.
Connects through Custom LINK-style cartridge: Web Payments SDK on the SFRA checkout page for tokenization, a registered payment processor in Business Manager, and server-side calls to Square's CreatePayment endpoint. Biggest gotcha: No cartridge exists, so your team owns the integration.
How it connects
Method
Custom LINK-style cartridge: Web Payments SDK on the SFRA checkout page for tokenization, a registered payment processor in Business Manager, and server-side calls to Square's CreatePayment endpoint.2
Maintained by
The merchant or its implementation partner (no maintained Square cartridge found)3
What works on this platform
Yes: a source confirms it on this integration. Not verified here: the gateway supports it, but no source confirms this integration exposes it. No: not available. A capability with no source either way is left off.
Square supports this; no source confirms it on this integration.
Capability status reflects the integration and documentation available at the time of verification, not necessarily every capability of the underlying gateway or platform.
Testing it
Register an application in the Square Developer Console to get Sandbox credentials. Load the Web Payments SDK from sandbox.web.squarecdn.com and allow pci-connect.squareupsandbox.com in the storefront's Content Security Policy. Charge with Square's Sandbox test tokens and test cards, for example cnon:card-nonce-ok or Visa 4111 1111 1111 1111. Point a Square webhook subscription at a public HTTPS controller on the On-Demand Sandbox, and check the x-square-hmacsha256-signature header on each event. Assert three things: the order's payment transaction ID matches the Square payment ID, refunds reach PENDING and later COMPLETED, and replaying a notification changes nothing.11
UAT-Ops runs integration flows like this against the real sandbox and keeps the evidence. Get one email when it opens.
Gotchas
No cartridge exists, so your team owns the integration
Square has no LINK cartridge for B2C Commerce, and no partner or open-source one turned up either. AppExchange's Commerce Cloud collection lists payment cartridges from PayPal, Cybersource, Adyen and others, but none from Square. GitHub searches found no repository. Chargent's paid multi-gateway listing leaves Square out of its supported set. So everything is on your team: payment processor registration, the checkout controller hooks, refunds and reconciliation. Every SFRA upgrade needs a regression pass, because no vendor ships fixes for this code.
Content Security Policy must allow Square's iframe and API hosts
The Web Payments SDK draws the card fields in frames served from Square's CDN, and it posts card data to Square's PCI endpoint. A storefront CSP that doesn't list those hosts under script-src, frame-src and connect-src breaks silently: the card field never appears. Sandbox and production use different hosts. That means a CSP that works on the On-Demand Sandbox can still fail in production unless both sets of hosts are included.
Square processes each payment in the currency of the seller's location, never the shopper's. Its guide does not say one account can hold locations in several countries, and its own advice for applications working across countries is a Square account per country, so a multi-site B2C Commerce realm selling in USD, GBP and CAD should plan for per-region credentials picked by site-level preferences. Cards issued abroad cost an extra 1.5% on top of the standard rate.
Refunds and some payment states finish asynchronously, so the cartridge needs a public controller that receives Square webhooks over HTTPS. It must answer with a 2xx status fast. If it doesn't, Square retries with backoff for up to 24 hours, and a slow order-update job can end up processing duplicate events. Sandbox events come from different IP addresses than production ones. Update any IP allowlist on the storefront or its CDN when you go live.
Last verified 2026-09-12 · Reviewed by a person 2026-09-25
Integration capabilities, requirements, pricing, availability, and vendor policies may change over time. UAT-Ops documents information based on the authoritative sources and testing available at the time of review.
Where newer information, testing, or vendor documentation materially changes a published claim, UAT-Ops may revise the page to reflect the most current verified information. Readers should confirm time-sensitive requirements with the relevant vendor before making production or purchasing decisions.