Account absent from quote search
Verify it was created from the lead and is enabled; do not create an unlinked duplicate merely to proceed.
In practice · B2B
A negotiated sale stays connected from first context to fulfillment.
Follow a fictional Northline opportunity through the records that matter. The story explains source-backed behavior; labeled frames reserve the actual software evidence for the dedicated demo phase.
Story 01 · intended outcome
A reviewed quote becomes an order without losing its identity.
A representative can begin with customer context, link the billing account, prepare an enabled product, review a negotiated quote, convert it, take payment and verify fulfillment. These are connected operations—not one magical submit button.
- Continuity
- BasketID 7841 remains the identifier when the quote is finalized as an order.
- Money
- Payment is recorded separately from quote conversion.
- Delivery
- Fulfillment is checked separately; a retry resumes fulfillment and does not issue another charge.
The record path
Seven deliberate checkpoints.
Qualify the lead
Search first, then create or update LeadID 1042 with company, contact, configured source and owner. Add the conversation as a note and set a FollowUpDate when another action is expected.
Create the commerce account
Use the lead’s Create Account action to create AccountID 220. Saving a lead alone does not create a billing account.
Prepare the product
Verify ProductID 240, identified to operators by product code NL-ACT-240, is enabled, has the intended product type and initial price, and that its fulfillment behavior is understood.
Build the quote
Select Northline Workshop Account, add the assembly, quantity and negotiated unit price, then record BasketID 7841.
Review before conversion
Check items, discounts, tax, shipping, total and separately saved notes. Conversion finalizes the same basket; it does not collect money.
Collect payment
Open checkout for BasketID 7841, confirm the configured processor or manual method and inspect the resulting payment record once.
Verify fulfillment
Read paid and fulfilled outcomes independently. If paid but unfinished, investigate the fulfillment error and use Retry Fulfillment rather than submitting another payment.
Exceptions are part of the workflow
What the operator does when the happy path stops.
Product absent
Check Enabled, product type and configuration before adding another SKU.
Delayed payment response
Do not assume failure and resubmit. Reconcile payment history and the current basket balance.
Paid but unfinished
Preserve the paid state, inspect the fulfillment error and retry fulfillment without another charge.
Technical evaluator
A real commerce API contract, with its ownership boundaries.
Commerce checkout is an authenticated Feeding Frenzy business route.
The generated JsonWs client calls /api/feedingfrenzy.admin.business/commerce-basket-operations/checkout-with-opaque-data. It accepts the exact fields below and returns BasketCheckoutResult. Authentication and installation URL are deployment concerns; they are intentionally not invented here.
Source-derived proposed sample request
{
"BasketID": 7841,
"PaymentProcessorID": 12,
"DataDescriptor": "opaqueDataDescriptor",
"DataValue": "opaqueDataValue",
"SavePaymentMethod": false,
"IdempotencyKey": "northline-basket-7841-attempt-01",
"BillingFirstName": "Avery",
"BillingLastName": "Chen",
"BillingZip": "00000"
}Source-shaped success response
{
"IsSuccessful": true,
"BasketID": 7841,
"Status": "Paid",
"Total": 250.00,
"TransactionID": "demo-transaction-id",
"MaskedPaymentMethod": "****1111",
"Code": null,
"Message": null
}Proposed, unrun sample: field names and result shape are source-derived; IDs, token values, amount, transaction and masked card are fictional Northline placeholders. This sample was not runtime-executed and is not evidence of a configured processor.
Error semantics
Invalid state fails explicitly: basket not found; voided, deleted or unfinalized basket; no billable total; missing idempotency key; or missing, disabled or wrong-provider processor. If payment succeeded but fulfillment failed, the typed result can be IsSuccessful: false, Status: "Paid", Code: "FULFILLMENT_PENDING", with the exception text in Message. Reconcile that paid basket and retry fulfillment; do not submit another charge.
| Integration | System of record | Direction | Trigger | Identity mapping | Retry / error behavior | Configuration owner |
|---|---|---|---|---|---|---|
| Checkout caller → Feeding Frenzy | Feeding Frenzy basket and payment records | Inbound authenticated business request | Explicit checkout after quote finalization | BasketID, AccountID, PaymentProcessorID and IdempotencyKey | Validate state; reconcile the basket/payment attempt before retry | Installation delivery team; caller credentials owned by the integrating party |
| Feeding Frenzy → payment processor | Provider transaction; Feeding Frenzy basket/payment record | Outbound charge/profile operation | Accepted checkout request | Transaction/profile IDs mapped to basket and payment attempt | Idempotency and paid-state checks prevent a blind second charge | Installation owner and payment-provider account owner |
| Feeding Frenzy → fulfillment/subscription processor | Feeding Frenzy basket; external subscription where configured | Outbound after successful payment | Successful payment completion | BasketID, product renewal and external subscription/profile IDs | FULFILLMENT_PENDING; Retry Fulfillment without recharging | Installation delivery team and external-provider account owner |
Source anchors: FeedingFrenzy.Admin.Business/CommerceBasketOperations.cs · generated CommerceBasketOperations.ashx.js and metadata JSON · FeedingFrenzy.Commerce/Services/BasketCheckoutService.cs.
Evidence boundary