Skip to content

ChargeOn Post-Configuration Testing Guide

The examples use Emily Ross at Summit Technologies and the $8,500 Summit - Q4 Expansion. Its payment link and customer checkout show the same $8,500 invoice total.

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 an installment plan and a subscription
  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, which is covered 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.

Confirm NMI with a test payment

For NMI, use a successful test payment in Part 2 to verify the connection.

Part 2: Instant Card Payment

  1. Open a test record and click Charge.
  2. Choose payment type Card and payment mode Instant Payment.
  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 and 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.

Allow time for bank settlement

A bank payment can show Pending while it settles. The scheduled transaction status job updates the record when the gateway confirms the outcome.

This is the only test in the guide 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.

    The same $8,500 Q4 expansion checkout for Emily Ross, with the amount and invoice service lines visible

  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 Schedule Payment.
  2. Set a date in the near future and save.
  3. Confirm a record appears with status Active.
  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 Active past its date almost always means the scheduled payment job is not scheduled. Check Setup → Scheduled Jobs.

Part 6: Test Installments and Subscriptions

  1. Start a charge and choose Installment Plan or Subscription. Test each mode.

  2. For Installment Plan, choose Bill until: N payments with Number of Payments from 2 to 600, Total reached with Per-Installment Amount, or End date with End Date. For Subscription, set Ends to Never or On date with Subscription Ends On. Choose a frequency: weekly, fortnightly (Biweekly on screen), monthly, quarterly, half-yearly or yearly. Use Frequency for Installment Plan and Bills Every for Subscription.

  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.

    The transaction list showing the completed $8,500 Summit Q4 expansion payment with its gateway and Success status

  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 payment, installment plan or subscription 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
You need to confirm a refund’s outcome Refund processing depends on the gateway and payment type Check the original transaction and linked refund, then compare their status and amount with the gateway dashboard. See Refund a payment
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
An installment plan or subscription 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