Jotform payment not working: the payment step

The payment step depends on the choices above it. A product, a quantity or a delivery answer decides whether the payment field shows and what the total adds up to. When a choice is missing from a rule, the buyer gets a payment field that expects a sum the form never calculated, a total of zero, or no field at all. They go back to the product page.

• The payment field: does it appear after each product and quantity a buyer can choose?
• The total on the payment step, checked against the item and quantity the buyer picked.
• Required questions hidden by a condition that still block the order from going on.
• The Pay control: does it open the provider's window, or does the screen change at all?
• Any error text on the payment step, read word for word, since it often names the field at fault.

A buyer does not read the form's logic. They pick what they want, type a quantity, and expect the total to agree. If the total is computed from a field that a choice hid, the sum drops to zero or to the wrong price. If the payment field follows a rule that some product never meets, it stays hidden, and the buyer reaches a last step with no way to pay. Both look like a failed order from outside, and neither produces an error the buyer can read.

Check it with the choices a real buyer would make. Pick the cheapest item, the most expensive, and the largest quantity, and read the total each time. A payment field that never appears points to a visibility rule. A payment field that appears with a total stuck at zero points to the price or quantity calculation. Record the two separately, because a buyer only sees a blank step, and the fix for each sits in a different rule.

When a buyer presses Pay, the provider's payment window has to open, and the way your form opens it decides whether it can. The window can open on top of the form or move the buyer to a separate page, and the buyer sees only that it appeared or did not. A browser's pop-up rule can stop that window, and the press then looks like it did nothing.

Test the Pay press in a phone browser and watch for a new screen or a blocked-window message. A real payment belongs to you: run one yourself in the provider's test mode with the test values the provider publishes, and never with a live card. What it can show is whether the press led to a new screen or left the buyer where they were.

A simulated buyer reads the form, picks a product and a quantity the way a buyer would, fills in the contact fields, and goes to the payment step. The run reports the total it saw, whether the payment field showed, and any error text on the screen. Then it stops, because it does not enter a card and cannot finish a payment. That stop is a limit of the test, not a gap in the report.

Run the same buyers again after each change to a product, a price, a condition or the payment setup, and keep one phone buyer in the set. Write down the total for each run so the change is visible. The run does not show whether money moved or whether the order reached your inbox. It does not open your provider account, so check the payout side and the test payment yourself.

A payment step breaks when a product is added, a price changes, or a campaign form reuses the same payment field with different rules. A new item with a missing price can zero the total for every buyer who picks it. Rerun the same buyers after each product or price change, and keep a phone buyer in each run.