Integrating PredictSpring with Salesforce

A retail architect draws a till on the left and a storefront on the right, then draws one arrow labelled orders. The arrow does not say which object is created, or what happens when the payment is taken and the order is not. The room treats the arrow as an integration. It is a poster. An integration names the system, the object, and the failure when the call does not land. Here the system is retail point of sale. The object is the order, and only after you write the mapping. The failure is a tender that never becomes an order.

PredictSpring is retail point-of-sale software. Salesforce completed the acquisition on 12 September 2024. The purchase does not replace B2C Commerce. If you run a web storefront on B2C Commerce, that storefront remains the storefront. The till remains the till. They can share a product code and a customer. They do not share a transaction until someone writes the map. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of PredictSpring on September 12, 2024."

#The system is the till

The system you are integrating is the point of sale a colleague uses in a store. It takes a tender. It prints or sends a receipt. It should tell an inventory location that a unit moved. That is a store system. B2C Commerce is a different system. It takes a web checkout and produces an order the storefront already understands. Putting both names in one box hides the boundary where integrations fail.

Name the pilot store. Name the tender types you already settle, in your own words: the card provider you use, cash if you take it, a gift card if finance has already approved it. Name the inventory system that must hear about the sale. Those names are yours. This page will not invent a connector to stand between them. A connector name would look like a product decision. The source does not give one.

Write what the till already records on a receipt. Store. Colleague. Time. Lines and product codes. Tender. Tax the way finance already calculates it. That list is the payload. If the list is only a picture of a website, you are still scoping the storefront. Put the sitemap back on the storefront quote. PredictSpring and the point-of-sale quote is where that scope is priced. This page is the landing rule.

#A store transaction is not yet an order

A customer pays at the counter. The till has a tender. B2C Commerce has no order. Those two facts can both be true. They stay true until a mapping says which till event creates which order, in which state, with which line items. Until that mapping is written, the transaction is a store sale. It is not a B2C order. Calling it an order in a workshop does not create the record.

The mapping has to be dull. Which identifier on the receipt becomes which identifier on the order. Which product code must already exist in the catalogue. What status the order is born in, so a fulfilment team does not try to ship a shirt the customer already holds. Who the customer is, and the rule when the sale was anonymous. An anonymous counter sale mapped to a guessed person is a privacy decision, not a default. Leave the person off the order until you have a rule your counsel has seen.

Returns make the mapping visible. A return of a store sale looks up the store transaction. A return of a web order looks up a B2C order. Those are different objects. A diagram that sends every return to "the order" will post a store return against a web order, or the reverse. Write the branch. The branch is the integration.

A store pickup of a web order is a crossing, not a merge. The storefront still owns the order until the handoff you define. The till may record that the goods were handed over. That recording is a status you name. It is not permission for the till to become the commerce system of record. One crossing can be a line on the diagram. "Integrate commerce" is a second programme.

#The failure is a tender that never becomes an order

The colleague takes payment. The receipt exists. The customer leaves with the goods. Overnight, finance looks for an order and does not find one. Or commerce looks for a payment and does not find one. The tender happened. The order did not. That is the failure this integration has to show. It is not a slogan about retail. It is a missing record.

The failure has a twin. The tender becomes two orders, because the till retried and the mapping did not carry an idempotency key you chose. The customer is not charged twice by the acquirer, but your commerce reports show two sales. Write the key you will use: store, register, receipt number, time. If you cannot name the key, you cannot tell a retry from a second sale. A retry that creates a second order is the same class of miss as a tender that creates none.

Do not hide the failure inside the word sync. Sync is not an object. Ask where the order is, an hour after the store closes, for a sale you watched. If nobody can open it, the call did not land. If someone can open it and the lines do not match the receipt, the call landed on the wrong shape. Both are defects. Fix the mapping before you add a second store. A second store multiplies the miss.

Network loss in the shop is part of the same test. Your colleagues already have a habit for a dead line. Write the habit. What they may still sell. How that sale is identified when the network returns, so you create the order once. A design that assumes the shop is always online will show a tender with no order the first time the link drops. The rehearsal is in the pilot store, with the network actually off.

#A sandbox does not clone B2C Commerce

Teams prove the till in a Salesforce sandbox and assume the storefront came with it. It did not. A sandbox does not clone B2C Commerce. The commerce realm you run is a separate system, with its own catalogue, its own prices, and its own orders. A sandbox full of Cases and accounts is not a shop. A test that creates a pretend order object in the sandbox, with no call to the commerce system, has not proved the mapping.

Say this in the test plan in one sentence. The order must appear in the B2C Commerce system you named, not only in a custom object you invented beside it. If you do not yet have a safe commerce place to write a test order, the integration is not ready to build. Building against a lookalike object trains the team to accept a tender that never becomes an order. That is the failure, practised.

This page will not name a cartridge, a hook, or an endpoint. Those names would be an API this source does not give. Your commerce owner knows how their storefront accepts an external sale, if it does. Ask them. If they say it does not, the mapping is a decision still to make, not a line you can draw as done.

Catalogue ownership stays with the storefront unless you have a separate decision. The till should use product codes the catalogue already has. A till that invents a code will take a tender for a product commerce cannot order. That miss looks like a payment success and a fulfilment failure. Put the code match on the diagram.

#What the diagram has to show

Three names, or it is a poster. System: PredictSpring as the retail point of sale, in a named pilot store. Object: the B2C order the tender must become, after the mapping. Failure: a tender that never becomes that order. You may add the inventory location and the receipt key, because those are how you prove the landing. You may not add a connector name, a price, a daily cap, or a current screen. The source does not give them.

Read it aloud. If the sentence needs a product logo to finish, it is not done. What happened to PredictSpring holds the ownership and the date. It does not draw this mapping. Do not copy a screen from memory onto either page.

#What you refuse to invent

A connector name would let a vendor search replace a mapping workshop. Refuse it. The integration is the map from receipt to order, plus the proof that the order exists in B2C Commerce. How your org posts that order is a build choice made with the commerce owner. This page has no fee schedule.

A price does not belong on the diagram. Licences you already hold can be named as products, with the amounts left in your contract. A daily transaction cap is a number the source does not publish. If operations knows a band for the pilot store, that band is yours. Do not borrow a figure.

Do not design the website here. Search, catalogue merchandising, and a new storefront are other quotes. A tender integration that also rebuilds the site will be accepted by opinion. Opinion will not show you the missing order.

Payment settlement stays with the provider you already use. The till records that a tender was taken. The order records that a sale exists. Chargebacks remain a finance process. A diagram that replaces the acquirer has left the brief.

#How you test that the call landed

Take one sale in the pilot store. Keep the receipt. Find the order in B2C Commerce, not in a spreadsheet and not in a sandbox object that only looks like commerce. Match line, quantity, product code, and tender. Match the key so a second send does not create a second order. Then run the offline case. Then run one return of that sale, and one return of a web order, and check they hit different rules.

If the order is missing, stop. Do not add stores. The failure you just saw is the one the diagram names. Fix the mapping. If the order exists only in the sandbox, you have not tested B2C Commerce. A sandbox does not clone it.

For the first trading days, read exceptions. Tenders with no order. Orders with no receipt. Orders created twice. Inventory that moved in the wrong location. A handful is a pilot. A pattern is a rule you missed.

When one store can show the order from the receipt every time, including after a retry and after a dead network, write the second store. Until then the diagram is a single door, a single mapping, and a single place you look for the order.

The implementation page prices tills, receipts, and the boundary. This page only insists that the boundary is visible. A partner who says the till now owns the web order has changed the system of record without a decision from you. That is the moment to stop.