Review and change Payment Processor settings safely

#Current boundary

Settings > Payment Processors opens the shared Global Settings screen with the Payment Processors tab selected and starts in the Payment Systems category. The visible fields, descriptions, setting IDs, control types, and available processors come from the current studio's settings data.

This page is not a universal processor setup wizard. Saving values does not by itself:

• open or approve a merchant account;
• enable a service in the processor's system;
• prove credentials are correct;
• migrate saved cards or ACH sources;
• confirm that live or test mode is appropriate;
• process a payment; or
• reconcile the software with processor settlement.

#Before you begin

• Confirm the processor, merchant account, legal entity, bank destination, currency, locations, and payment methods with the studio's finance owner.
• Obtain settings from the processor or an authorized support contact through an approved secure channel.
• Record the current non-secret setting IDs and display values.
• Identify every workflow that can be affected: Online Client checkout, staff checkout, saved payment methods, scheduled payments, auto payment, refunds, receipts, and reconciliation.
• Choose a maintenance window with no checkout or payment batch in progress.
• Prepare a processor-approved test account, fictional client, small test item, and reconciliation checklist.
• Know how to restore the previous approved non-secret settings if verification fails.

Warning: Changing a processor, account, location mapping, credential, payment-method mapping, or live/test setting can cause payments to fail, route to the wrong account, create records that cannot be reconciled, or make existing saved sources unusable. Do not explore these settings in a live studio.

Warning: Never place account IDs, access keys, passwords, secrets, API keys, full card or ACH details, or unmasked tokens in screenshots, support tickets, chat messages, spreadsheets, or this manual. Use the studio's approved secret-sharing process.

#Understand the settings

The exact labels differ by studio and processor. Use each field's on-screen description and setting ID as the source of truth.

Typical groups of questions include:

The older human-written help material is useful because it asks these operational questions, but its processor names, recommended values, licensing details, and live-mode instructions are not current product authority.

#Review the current configuration

1. Select Settings > Payment Processors.
2. Confirm the page title is Global Settings and the Payment Processors tab is selected.
3. Confirm the category is Payment Systems, or choose the relevant payment category shown for this studio.
4. Read each setting's description, ID, current display value, and Read-only state.
5. Record non-secret settings in the approved change worksheet.
6. For a password control, record only Set or Not set.
7. Search for related account, location, payment-method, test/live, card, and ACH settings without changing them.
8. Map each intended edit to a downstream test.

Do not copy the page wholesale. It can contain secrets or values that reveal the studio's payment architecture.

#Change approved settings

Change the smallest coherent group that can be tested together.

1. Stop payment activity for the maintenance window.
2. Open Settings > Payment Processors.
3. Confirm the studio and the setting ID before editing a field.
4. Enter only the approved value.
5. For a secret field, leave New password blank to keep the stored value. Entering a new value replaces the stored value when the page is saved; the current control is single-entry, so verify the approved value before submitting.
6. Repeat only for fields in the approved change set.
7. Turn on Show changed only.
8. Compare every Changed field with the worksheet.
9. Use Reset if the page contains an unintended unsaved edit.
10. Select Save changes.
11. Confirm the saved-settings message.
12. Reload the page and verify the non-secret values and the expected Set state for secrets.

Important: Reset discards unsaved edits from the current page load. It does not restore settings that were already saved.

Important: A saved-settings message confirms that settings rows were updated. It is not a processor connection test and is not proof that a payment was authorized or settled.

#Verify in stages

Use the processor's approved sandbox or test mode when one is available and correctly configured. If the processor does not provide a safe test path, coordinate the smallest approved live verification with the finance owner and support contact.

#1. Verify availability without submitting

1. Open the Online Client as a fictional signed-in client.
2. Confirm only the approved card, ACH, or other payment choices appear.
3. Open the staff Shopping Cart with a fictional client and item.
4. Confirm the intended payment account and masked-source choices appear.
5. Stop before the final submit.

This step proves only that the interface can build a payment choice. It does not prove processor connectivity.

#2. Complete one approved test

1. Use a processor-approved test source or the explicitly approved live method.
2. Confirm the fictional client, location, item, amount, payment account, and mode.
3. Submit once.
4. Record the time, amount, masked method, and non-secret processor reference.
5. Confirm the interface reports a processor-aware result.
6. Do not retry an unclear response until local and processor records have been checked.

#3. Reconcile the result

Confirm all applicable evidence:

• the order or purchase was created once;
• the charge is correct;
• the payment exists and is allocated as intended;
• the processor response or reference is present;
• the transaction appears in the correct processor account and mode;
• fees, tax, and net amount match the approved expectation;
• the receipt does not expose sensitive data; and
• a void, refund, or test cleanup is completed when required by policy.

For ACH, a submitted or accepted instruction is not proof that funds have settled. Follow the processor's status and return process.

#4. Verify other affected workflows

Card and ACH, new and saved sources, Online Client and staff checkout, multiple accounts, scheduled payments, and refunds can use different paths. Test only the paths the studio intends to use, but do not treat one successful card checkout as proof of all of them.

#What happens next

Saving updates writable active settings rows for the current studio and clears relevant settings, feature, and client-facing caches. Payment services read those values when they build or submit later requests.

Existing orders and payments are not rewritten. Existing saved payment sources can remain tied to their original processor customer, merchant account, or location context. A newly selected processor does not automatically convert those sources.

A scheduled payment remains a future instruction. Updating processor settings does not prove that the future payment will run or settle.

#Confirm it worked

Do not mark the processor setup complete until:

1. the approved non-secret setting values persist after reload;
2. secrets show the intended Set state without being exposed;
3. the correct methods and account context appear in each required checkout;
4. one approved transaction has an unambiguous processor-aware result;
5. the local order, charge, payment, and allocation agree;
6. the correct processor account contains the corresponding test record;
7. card and ACH have been checked separately when both are enabled; and
8. the finance owner has reviewed the reconciliation evidence.

If no approved transaction was completed, record the configuration as saved but unverified. Do not describe it as active, connected, tested, or working.

#Troubleshooting

#The expected setting is missing

Search by description and setting ID. The row can be absent, inactive, placed in a different category, or unavailable to this studio or role. Ask an authorized administrator or support contact to confirm the required settings inventory.

#A field is read-only

Do not try to bypass it. Record the setting ID and coordinate the change through its supported management path.

#Save reports zero settings changed

The submitted values can match what is already stored, the row can be read-only or inactive, or the intended field can use a different ID. Reload before entering the value again.

#A secret still says Set after leaving the field blank

That is expected: a blank New password field keeps the current stored secret. It does not reveal or validate the value.

#The payment method does not appear at checkout

Check the selected processor, account, location, payment-method mapping, card or ACH enablement, studio feature settings, role, and cart context. Processor-side enablement can also be required.

#Checkout reports a processor or credential error

Stop. Do not repeatedly submit. Compare the current studio, mode, account mapping, credential state, processor status, and request time with the approved worksheet. Check whether a local order or payment was created before trying again.

#Saved cards or ACH sources disappeared or cannot be used

The sources can belong to a different processor, merchant account, customer profile, or location. Do not re-create or move them in bulk until an authorized payment specialist confirms the migration path and client authorization requirements.

#The local payment exists but the processor has no matching transaction

Treat the result as unresolved, not paid. Review the non-secret processor reference, local status, request logs available to authorized support, and reconciliation reports. Do not create an offsetting payment or retry until the original result is understood.

#A processor transaction exists but the local records are incomplete

Do not submit another charge. Record the processor reference and amount, then use the approved recovery and reconciliation process with support and the finance owner.

#Related articles

• Find and change Global Settings safely
• Sell an item with the staff Shopping Cart
• Manage saved cards and ACH sources
• Review scheduled payments and scheduled charges
• Review payment history and make corrections
• Why features and menus can differ