The customer portal: the link your customer opens to pay
Customer order portal
Every order in ibakepro has a page of its own. The customer reaches it through a link, with no account and no password, and from that page they can read the order, choose between quote options, answer the questions you attached to the product, accept your policies and pay. It is on every plan.
Why it exists
The alternative is a thread. You send a photo of the quote, they ask what the total was, you scroll back, they say yes, you ask for the deposit, they pay into the wrong account and three weeks later nobody can find the message where the flavour was agreed. Everything that matters about the order ends up scattered across a conversation that only one of you can search.
The portal is the same order, from the other side. What the customer sees is what your dashboard holds, and what they answer lands back on the order rather than in your inbox.
Getting in
The link is the credential. There is nothing to sign up for, which is the whole point for a customer who is buying one cake from you and will not do it again for a year.
While the order is live, the link opens it directly. Once the order is complete, the portal asks for a code first: a six-digit code emailed to the address on the order, with a limited number of attempts, and the email is masked on screen until the code is accepted. That step guards the finished record, with its receipt, photos and history, rather than the working order.
What the customer can do
Pick an option. If you sent a quote with more than one version, the options appear as cards. Choosing one reprices the order and rebuilds the payment schedule around the new figure, so the deposit they are then asked for is the deposit for the version they picked, not the one you priced first. The choice is stamped on the order timeline.
Answer your questions. Custom fields you marked as portal-visible appear for them to fill in. An internal field never appears in the portal and can never be filled in from it.
Pay. A deposit, a scheduled instalment or the balance, through your own payment gateway, including wallet buttons where the device supports them. If you have tipping switched on, the tip options you configured appear here. If you have upsells attached, they are offered before payment.
Pay a different way. If you take bank transfer, cash or cheque, those methods appear as you configured them. Where you require evidence, it is required: no attachment, no submission. Payments are checked against what is already committed on the order, so a customer cannot pay the same instalment twice or overpay the balance.
Accept your policies. Terms, privacy and refund acceptance are recorded against the order with the timestamp, rather than assumed.
What happens on your side
A card payment is confirmed by the gateway, not by you: the payment record is completed when Stripe reports the charge succeeded. A manual payment is different. It is recorded as pending verification and waits for you to confirm the money arrived, unless you have deliberately configured that method to confirm itself. That is the human checkpoint, and it is there because "customer says they transferred it" and "the transfer landed" are different facts.
Design decisions
- The customer chooses an option, answers your fields and pays. Changing quantities, dates or products goes through you: a conversation, then an edit you make.
- Confirming a manual payment arrived is always yours, unless you set that method to auto-confirm.
- Portal visits are recorded, and the link is deliberately stripped out of any analytics that leave the page.
- Each order has a private link of its own, with nothing for the customer to sign up for.
- The email or SMS you send is what puts the link in front of the customer.