Create offline Payment Types so staff can record Cash, Check, and Account Credit payments that are not processed through Stripe.
An offline Payment Type lets your staff record a payment that does not run through Stripe — for example Cash, Check, or Account Credit. A Payment Type is a configuration record (a Payment_Type__c record) that tells fusionCore how money can move for a given Business Unit, which payment method it uses, and where the option appears.Offline Payment Types are always staff-facing. They never appear to portal members.
You need the FC_Commerce_Manage_Config_Data permission set, which grants full create and edit access to Payment_Type__c records.
The Business Unit you are configuring must already exist. A Business Unit (Business_Unit__c) is a branded operating division of your organization.
The GL Account you plan to use as the deposit account must belong to the same Business Unit. The deposit-account lookup is filtered to GL Accounts of the matching Business Unit.
Open the Business Unit and start a new Payment Type
Navigate to the Business Unit for which you want to create the Payment Type, then click New on its Payment Types related list.
Click New on the Payment Types related list
2
Choose the Payment record type
Select Payment as the record type, then click Next. The Payment record type (FC_Payment) is the checkout/pay option you want for an offline method.
Select the Payment record type
3
Fill in the core fields
At a minimum, define the following for an offline Payment Type:
Payment Type Name — a descriptive name, for example Society of Innovators Check or SOI Cash.
Business Unit (Business_Unit__c) — the division this Payment Type belongs to.
Payment Method (Payment_Method__c) — the medium of payment. For offline types this is Cash, Check, or Account Credit. Do not pick Card, ACH, Alipay, or WeChat Pay for an offline type; those require a Payment Provider Account and will block the save (see Limitations and common pitfalls).
Deposit Account (Deposit_Account__c) — the GL Account that should receive the funds. The lookup only shows GL Accounts in the same Business Unit.
Display Payment Type (Display_Payment_Type__c) — controls where the option appears. The full picklist is Portal and Staff, Portal, Staff, and Disabled. For offline Payment Types, set this to Staff. Choose Disabled to keep the record but hide it everywhere.
Refund Behavior (Refund_Behavior__c) — controls how the Payment Type handles refunds. The picklist is Cannot Refund, Refund only if original payment, and Valid for All Refunds.
Staff Order (Staff_Order__c) — the sort position of this Payment Type in the payment-method dropdown when staff take a payment.
For offline Payment Types you cannot set Display Payment Type to Portal or Portal and Staff. Only Stripe Payment Types can appear in the portal.
Core fields on a new offline Payment Type
4
Set the System Information components
The System Information section points the pay and refund screens at the right Lightning Web Component (the front-end component that collects the payment). Set the components to match the payment method:
Payment method
Payment Component (Payment_Component__c)
Refund Component (Refund_Component__c)
Cash
FCORE_PAY/orderPaymentCashOrCheck
FCORE_PAY/orderRefundCash
Check
FCORE_PAY/orderPaymentCashOrCheck
FCORE_PAY/orderRefundCheck
Account Credit
FCORE_PAY/orderPaymentAccountCredit
FCORE_PAY/orderRefundAccountCredit
These fields do not appear on the Payment Type layout by default. Implementation teams typically use a field-editing browser tool, such as Salesforce Inspector, to view and set them.
Configuring Automatic Approvals for Offline Payment Types
Offline methods such as Cash and Check have no payment provider to confirm the money moved, so by default their financial events stay in a pending status until someone approves them. You can have fusionCore mark them as succeeded automatically.On the Payment Type record, set either of these checkboxes to True:
Auto-Update Payment FE To Succeeded (Auto_Update_Payment_FE_To_Succeeded__c) — auto-marks the payment financial event as succeeded.
Auto-Update Refund FE To Succeeded (Auto_Update_Refund_FE_To_Succeeded__c) — auto-marks the refund financial event as succeeded.
If you do not want automatic approvals, leave the checkboxes unchecked.
Auto-approval is for offline methods only. These auto-succeed checkboxes cannot be combined with a Payment Provider Account. If a Payment Provider Account is set and either checkbox is true, the save is blocked. Provider-backed events (such as Stripe) get their real status from the provider, so the shortcut does not apply to them.
Provider methods are not offline methods. If you pick Card, ACH, Alipay, or WeChat Pay, the save fails unless you also set a Payment Provider Account. These are online methods; configure them as Stripe Payment Types instead.
Only one Account Credit Payment Type per Business Unit. Saving a second Account Credit Payment record for the same Business Unit is blocked. Reuse the existing one.
Valid for All Refunds plus a provider account is rejected. This combination is blocked at save. It does not affect pure offline types, but watch for it if you later add a provider account.
A deposit account in use cannot be deleted. Once a GL Account is set as the deposit account on any Payment Type, it cannot be deleted until you reassign it. Deleting the Business Unit instead simply clears the lookup.
Missing currency match can hide the option. In a multi-currency org, if Supported Currencies (Supported_Currencies__c) is populated but omits the order’s currency, the Payment Type silently disappears from the pay screen. Leave it blank to support all currencies. In a single-currency org this field has no effect.
There are no validation rules to inspect. Every rule above is enforced in code, not as a declarative validation rule, so you will not find these guards under Setup → Validation Rules. The save error message tells you which rule fired.
⌘I
Assistant
Responses are generated using AI and may contain mistakes.
