The Product Orders area allows the card owner to review and manage purchases submitted through products displayed on public VCards.
A Product Order can contain information such as:
The customer dashboard includes a dedicated Product Orders menu separate from Appointments, Inquiries, and WhatsApp Product Orders.
The Product Orders area also provides a dedicated order-details view and a downloadable PDF invoice operation.
The Products section and Product Orders section serve different purposes.
Use Products to create and manage the items displayed through a VCard.
Product information can include:
Use Product Orders to manage purchase transactions created when visitors buy those products.
Changing a Product does not create an order. An order is created through the visitor’s purchase process.
A Product Inquiry is not the same as a Product Order.
A visitor asks a question about a product.
Example:
Is this product compatible with my current system?
A visitor provides the required customer information, selects a payment method, and completes the applicable purchase process.
Do not fulfill a Product Inquiry as though it were a completed order.
The dashboard contains separate areas for:
Created through products displayed directly in a VCard’s Products section.
Created through a connected WhatsApp Store.
An order appearing in one area should not be expected to appear automatically in the other.
Before visitors can submit an order:
Review the public product before enabling sales.
To display the Products section:
A saved product cannot receive public orders when visitors cannot reach it.
Product purchases can use payment methods configured for the account.
The programmed purchase workflow contains active paths for:
Only payment methods that have been configured correctly should be presented to customers.
Payment-provider credentials belong in the account’s payment settings, not inside a Product description or public VCard field.
A Product can use its assigned Currency. When the Product does not have its own Currency, the purchase process can use the account’s default Currency.
Before accepting orders, confirm that:
Do not change only the Currency label without reviewing and converting the actual price where necessary.
Some payment methods have specific currency requirements in the programmed workflow.
Examples include:
Iyzico is restricted to its programmed supported currencies, and PayPal, Paystack, and Flutterwave also validate the selected Currency against their supported lists.
When a payment method rejects the Currency, use a compatible provider or correct the Product and account Currency configuration.
Manual Payment allows a visitor to submit an order without completing an automated gateway transaction.
Before offering it:
A manual order confirmation or email does not, by itself, prove that funds were received.
The visitor generally begins by:
The selected template controls the exact button text and presentation.
The programmed Product purchase request requires:
The purchase interface can also collect a Telephone Number.
The customer should provide an address that is sufficiently complete for the intended delivery or fulfillment process.
The Name should identify the person or organization placing the order.
Examples:
Avoid entering placeholder information during real purchases.
For authorized testing, identify the order clearly.
Example:
The Email is required and must use a valid email format.
It may be used for:
A correctly formatted address may still be nonexistent or entered incorrectly. Review unusual addresses before shipping a high-value order.
The purchase process can collect the visitor’s Telephone Number.
It may be useful for:
Use the number only for purposes connected to the order unless another lawful and approved basis exists.
The Address is required.
The customer should include information appropriate to the delivery method, such as:
The Product Order form should not be treated as a complete shipping-address verification service. Staff should review incomplete or unusual addresses before dispatch.
The visitor must select an available Payment Method.
The purchase then follows the selected method’s programmed process.
Possible outcomes include:
The visitor should not repeatedly submit the order while the first payment attempt is still processing.
When the VCard contains a Privacy Policy or Terms and Conditions, the Product purchase process requires the visitor to accept the associated agreement control.
A purchase cannot proceed when the required agreement is not selected.
Test this process after changing the VCard’s policies.
The programmed VCard Product purchase request is based on one selected Product.
It does not expose a standard shopping-cart Quantity field in the core Product-order request.
A Product Order should therefore be treated as the purchase of the selected Product record rather than a multi-item shopping cart.
The connected WhatsApp Store uses a separate ordering system and may provide a different shopping experience.
The Product transaction records the Product’s saved Price as the order Amount.
Before publishing a Product, confirm that the Price includes or excludes the appropriate charges according to the business’s actual policies.
Do not assume that the Product Order process automatically calculates:
unless those calculations have been separately implemented and publicly tested.
For an automated payment method, the application creates or completes the applicable payment session through the selected provider.
The order may not be fully recorded until the provider’s successful return or payment-confirmation process has completed.
Do not ask a customer to pay a second time until the first payment has been checked in:
When Manual Payment is selected, the application creates a Product Transaction containing:
The order is recorded immediately through the manual-purchase process.
Staff must verify the payment before dispatching or delivering the Product.
The application contains separate Product Order email notifications for:
For manual purchases, the emails are sent when the corresponding account settings are enabled:
The email data can include:
Review the receiving addresses and mail configuration before relying on these notifications.
An order email may fail because of:
The Product Orders dashboard should be reviewed regularly even when emails normally work.
From the main dashboard:
Product Orders appears as a dedicated customer-dashboard destination.
The list is used to identify and manage saved Product transactions.
Depending on the current table layout, order information may include:
Use the order-details action for the complete saved information.
A practical order-review process is:
Do not rely only on an email notification.
Select the View or Order Details action beside the transaction.
The interface uses a dedicated Product Order Details view for the selected record.
The saved transaction can contain:
Review all available information before changing the status.
Confirm that:
When several VCards sell similar Products, confirm the Product’s originating business or VCard before fulfillment.
Review:
Contact the customer when:
Do not change the meaning of the customer’s submitted information without recording the correction through the organization’s approved process.
Compare the transaction Amount with:
Do not fulfill an order when the amount is incorrect or the payment remains unresolved.
The Payment Type identifies how the customer attempted or completed payment.
Examples include:
For automated methods, verify the corresponding provider record when a dispute or inconsistency exists.
For Manual Payment, verify receipt directly through the approved financial account.
Product Order records represent customer-submitted transaction information.
The management workflow is centered on:
Do not treat the Product Orders area as a customer-profile editor.
When the customer corrects an address or contact detail:
The Product Order workflow provides a dedicated status-update operation.
The interface language includes:
Use the statuses consistently so staff can understand the current fulfillment stage.
Use Pending when:
Pending should not be used indefinitely without follow-up.
Use Dispatched when the Product has been released for delivery or shipment.
Before selecting it, confirm that:
The Product Order record does not provide a dedicated tracking-number field in the core transaction information.
Send tracking details separately when available.
Use Delivered when there is a reasonable basis to conclude that the Product reached the customer.
Possible confirmation includes:
Do not mark an order Delivered merely because it was Dispatched.
Use Cancelled when the order will not be fulfilled.
Possible reasons include:
Document the reason outside the Product Order record when the interface does not provide a cancellation-note field.
To update an order:
The status-update operation saves the selected value and returns a Product status update confirmation.
Changing an order to Cancelled does not automatically mean that a payment-provider refund was completed.
Refunds must be processed through the appropriate:
Confirm the financial result separately.
The programmed Product status-update operation saves the new Status but does not itself send a customer status email.
After changing the order to Dispatched, Delivered, or Cancelled:
Do not assume that changing the dashboard status informed the customer.
The Product Orders feature provides a dedicated PDF invoice-download operation.
To download it:
The application has a specific Product Order PDF download route.
Before sending the invoice, confirm that it shows the correct:
Also confirm that:
A Product Order Invoice documents the order.
It should not automatically be treated as proof that an unpaid or manual transaction has settled.
For Manual Payment, verify the financial account before describing the invoice as paid.
For automated methods, verify the provider record when confirmation is uncertain.
The generated Product Order Invoice may not automatically satisfy every tax, accounting, or regulatory requirement.
Review whether the business must include:
Use an approved accounting system when additional invoicing requirements apply.
For physical Products:
For digital Products:
Do not place reusable private download credentials in the public VCard.
A Product may represent a package or deliverable that requires staff work.
Examples:
In these cases, establish an internal workflow for:
The Product Order record alone is not a project-management system.
The core Product Order workflow should not be assumed to provide full inventory control.
Maintain appropriate stock records when the business sells limited physical items.
Before accepting or dispatching an order, verify that the Product remains available.
The saved Product Transaction contains the customer’s Address, but the core order data does not provide dedicated fields for:
Maintain these details in the approved shipping or fulfillment system.
For a Manual Payment order:
A screenshot can be altered or may show a pending transaction.
Do not rely on a screenshot alone.
Verify:
A manual Product Order email may be sent when the order is recorded, before staff independently verify the funds.
The customer email should therefore not be interpreted as final payment approval unless its wording and operational process clearly establish that meaning.
Possible indicators include:
Verify the payment-provider transactions before cancelling or fulfilling either record.
Do not issue a refund before confirming whether both payments actually settled.
Changing the Product’s current Price affects future visitor purchases.
An existing Product Order should be handled according to the amount recorded for that transaction.
Do not request an additional amount merely because the public Product Price changed after the customer ordered, unless an approved correction process applies.
A renamed Product can make earlier records harder to interpret.
Maintain an external record when a Product undergoes a major name or identity change.
Do not reuse one Product record for an entirely unrelated item.
Review Product Orders before deleting a Product.
Removing the Product while active transactions still require fulfillment can make order identification and historical review more difficult.
A safer process is:
Product Orders may contain personal information, including:
Restrict dashboard access to authorized users.
Do not share order details through public messages or unsecured channels.
The Product Order record should not contain complete payment-card credentials.
Payment details are handled by the configured provider.
Never ask a customer to send:
through an ordinary email or VCard inquiry.
The VCard Privacy Policy should accurately describe Product-order data, including:
Before accepting orders, publish accurate information concerning:
The platform includes settings for Terms and Conditions, Refund and Cancellation Policy, and Shipping and Delivery Policy. Keep them consistent with the business’s actual practices.
Review the list for:
When additional operational detail is needed, retain:
The Product Orders area is not a complete shipping, inventory, CRM, or accounting system.
Periodically confirm whether the account should send Product Order emails to:
Submit an authorized test after changing the settings.
Confirm that the message contains current branding and accurate contact information.
Confirm that:
Confirm that the visitor entered:
Also confirm that the Product still exists and the browser session remains active.
Confirm that:
Do not place provider secrets in the Product or VCard editor.
Review:
Use a compatible provider or correct the Currency configuration.
A cancelled provider checkout may prevent the order from completing.
Before asking the customer to retry:
Do not ask the customer to pay again immediately.
Review:
Escalate unresolved payment discrepancies through the approved financial process.
This is expected for the programmed Manual Payment path.
The order is recorded when the manual purchase form is submitted.
Verify the funds before dispatching the Product.
Confirm:
Review:
Do not alter financial records without preserving an audit trail.
Confirm that:
When the record cannot be found, confirm that it was not removed or associated with another account.
Changing the Product Order Status does not itself send the customer a status email through the inspected update operation.
Contact the customer separately and provide:
as applicable.
Confirm that:
Try another browser when the order exists but the file does not open.
Review the underlying:
Do not manually alter a generated invoice in a way that misrepresents the original transaction.
Use the approved accounting process when a corrected formal invoice is required.
Review the payment provider before fulfilling or refunding.
The visitor may have:
Determine the financial result before changing either Status.
Before relying on Product Orders, confirm that:
At the end of this chapter, the user should understand how VCard Product Orders are created, how to review customer and payment information, verify Manual and automated payments, update orders through Pending, Dispatched, Delivered, and Cancelled stages, download Product Order invoices, protect customer information, and troubleshoot purchasing or fulfillment problems.