Skip to content

ChargeOn post-configuration testing guide

Your setup is complete. This guide proves it works before real money is involved.

Work through it in order. Each part builds on the one before, and a failure early on will cause confusing failures later.

Who does this: the administrator who did the setup, or a tester working alongside them. How long: about half a day for the full run.

Use test credentials and test cards throughout

Every gateway publishes test card and bank details. Use those, on a sandbox or test account. Never use a real customer's details, and never process a live charge to see whether it works.

What you will do

  1. Confirm the setup is intact
  2. Test an instant card payment
  3. Test a bank payment
  4. Test a payment link, as your customer sees it
  5. Test a scheduled payment
  6. Test a recurring payment
  7. Test refunds
  8. Confirm the records and reports are right
  9. Prepare to go live

Part 1 — Confirm the setup is intact

Before testing behaviour, confirm the foundations. Each of these takes a moment and saves an hour of confused debugging.

Check Where You should see
ChargeOn is installed Setup → Installed Packages ChargeOn listed
Permission sets are assigned Setup → Users → your test user ChargeOn access on the user doing the testing
The site is active Setup → Sites Active, home page set to the payment link page
Guest sharing rules exist Setup → Sharing Settings Rules for your payment object, ChargeOn, customer payment method, payment gateway, payment gateway customer, recurring payment, payment link, invoice, template configuration
The Charge button is present Open a test record The button appears
Your mapping is saved Global Settings → Object and Rules Your object, amount field, payer and gateway all populated
The gateway is active and verified Global Settings → Payment Gateways Active, with a successful verification (except NMI — see below)
You are pointed at the test environment The gateway record Sandbox or test, not production
Background jobs are scheduled Setup → Scheduled Jobs The jobs you scheduled, each with a next run time

Do not start testing until every row passes

A missing sharing rule shows up as a payment link that fails for your customer but works for you, which is one of the harder things to diagnose after the fact.

NMI verification always fails

NMI provides no way to check credentials, so its Verify Credentials reports failure regardless. For NMI, treat a successful test payment in Part 2 as your verification.

Part 2 — Instant card payment

  1. Open a test record and click Charge.
  2. Choose payment type Card and payment method Instant.
  3. Enter the gateway's test card details.
  4. If the option to save the payment method is offered, run this test twice — once accepting, once declining — so you know both paths work.
  5. Complete the payment.

What you should see:

  • A confirmation on screen.
  • A new transaction in Transaction History with status Success, the right amount, the right gateway, and payment type Card.
  • The same transaction in your gateway's own dashboard, for the same amount.
  • Where you accepted saving the method, a stored payment method against the customer.

Part 3 — Bank payment

Repeat Part 2 with payment type Bank, using the gateway's test bank details.

What you should see: a transaction with payment type Bank and a correct status.

Bank payments do not settle instantly

A bank payment will often sit at Pending rather than moving straight to Success. That is normal and is not a failure. Status updates arrive later, which is what the transaction status job you scheduled is for.

This is the most important test in the guide, because it is the only one that exercises the public access path your customers use.

  1. From the Charge component, choose Payment Link and enter an amount.
  2. Generate the link.
  3. Confirm a transaction is created with payment type Payment Link and a status such as Pending, carrying the link address.
  4. Confirm a QR code was generated.
  5. Copy the link and open it in a private or incognito window. This is the point of the test — it simulates someone with no Salesforce login.
  6. Confirm the page loads, and shows the right amount and any invoice line items.
  7. Pay it with test card or bank details.
  8. Confirm the transaction status updates to success.
  9. If emails are enabled, confirm your test address received the link and a receipt.

What you should see: a payment completed by a visitor who never logged in, and a transaction updated to match.

A normal browser window will not test this

In your own browser you are logged in, so the page will work for you whether or not the guest permissions are right. Private browsing is what catches the problem.

Part 5 — Scheduled payment

  1. Start a charge and choose Scheduled.
  2. Set a date in the near future and save.
  3. Confirm a record appears with status Scheduled.
  4. Confirm you can edit the date before it runs.
  5. On a second scheduled payment, use Abort, and confirm it is cancelled and never charges.
  6. Wait for the first one to run, and confirm it processes automatically and creates a successful transaction.

What you should see: one payment that ran on its date without anyone touching it, and one that was cancelled and did not.

If it never runs

A scheduled payment that stays at Scheduled past its date almost always means the scheduled payment job is not scheduled. Check Setup → Scheduled Jobs.

Part 6 — Recurring payment

  1. Start a charge and choose Recurring.
  2. Choose a basis — count, final amount, end date or subscription — and a frequency.
  3. Use the preview to check the schedule before confirming. Verify the dates, the amounts and the number of charges are what you expect.
  4. Save, and confirm the first payment processes.
  5. Pause the plan, and confirm no further charges occur.
  6. Resume it, and confirm billing continues.
  7. Cancel another plan, and confirm no further charges are generated.

What you should see: a plan that charges on schedule, and stops and starts on command.

Part 7 — Refunds

  1. Open a successful transaction and click Refund.
  2. Process a partial refund, entering an amount, a reason and a note.
  3. Confirm a linked transaction is created with status Refunded.
  4. On a different transaction, process a full refund.
  5. Confirm the customer receives a refund email, if emails are enabled.
  6. Confirm both refunds appear in your gateway's dashboard.

What you should see: refunds in ChargeOn and at the gateway agreeing on amount, with the original transaction still visible and linked.

Part 8 — Records and reports

  1. Open Transaction History and confirm every test transaction is listed with the right customer, amount, status, gateway, payment type and timestamp.
  2. Open the ChargeOn reports and dashboards and confirm your test transactions appear.
  3. Check the Unresolved Transactions tab. It should be empty. Anything sitting there is a payment that did not complete cleanly, and is worth understanding before you go live.
  4. Check the Error Logs. Investigate anything unexpected.

What you should see: every payment you made accounted for, and nothing unexplained.

Part 9 — Prepare to go live

Only once every part above has passed.

  1. Decide the date and who is doing it.
  2. Replace test credentials with live credentials on each gateway record.
  3. Switch each gateway record's Environment from Sandbox to Live.
  4. Run Verify Credentials again against the live credentials.
  5. Confirm your background jobs are still scheduled.
  6. Take one small real payment — a genuine charge of a token amount, on a real card — and refund it. This is the only test that proves the live path works end to end.
  7. Confirm both the charge and the refund appear at the gateway.

Clear the test data first

Test transactions in a production org distort your reporting from day one and are awkward to remove later. Decide what happens to them before you switch credentials, not after.

What you should see: one real payment taken and returned, everything reconciling, and no test data left where it will be mistaken for revenue.

If something went wrong

Symptom Likely cause What to do
The payment link works for you but fails for a customer Guest user permissions or sharing rules Re-test in a private window. Check every sharing rule in Part 1
A bank payment sits at Pending and never moves Either normal settlement time, or the status job is not scheduled Wait one business day, then check Setup → Scheduled Jobs
A scheduled or recurring payment never runs The relevant job is not scheduled Quick start guide, Part 7
No emails arrive Deliverability is not set to All Emails Prerequisite guide, Part 2
A refund fails at the gateway but appears to succeed in ChargeOn The gateway does not support refunds for that payment type Check the gateway's own dashboard. Not every gateway supports every refund path
A transaction is missing but the gateway took the money The payment succeeded and recording did not Look in Unresolved Transactions — this is exactly what it is for
A recurring plan charged on a different gateway than expected The first charge failed and fell back to a backup gateway This is by design. The plan stays on that gateway for its lifetime