Checking access…

Skip to main content
Version: v2

Merchant Settings

info

This page documents internal CCG onboarding configuration. If you're a merchant looking for V2 onboarding guidance, see Direct-to-V2 Onboarding or the V1 to V2 Migration Guide.

🔒 InternalInternal information — not visible in the public (merchant) site.

Merchant Settings Configuration​

Configure the following settings as part of onboarding:

Payment Methods​

  • Types Supported: Card, Bank Account , Health Savings Account
  • Special Card Types: Manufacturer Card
  • Channels: Email, Text, Webform, GooglePay, ApplePay, TelePhonic Entry

Additional Features​

Customer Find Logic​

Transaction Metadata​

  • Payment Metadata: Custom fields for payment tracking.
  • Refund Metadata: Custom fields for refund tracking.

Sender Information for Communication Channels​

  • Sender Email Addresses
  • Phone Numbers

Reports​

  • Enable payout reports: payoutReportsEnabled
  • Enable transaction-level fee reports: transactionLevelFeeReportEnabled
  • Reports

V2 Configuration Notes​

  • Split tender (splitTender.enabled, default false) — see below. This is independent of the HSA payment-method type and the customer-applied HSA card designation: enabling split tender does not affect either, and setting up HSA-related payment methods does not require split tender. See the "Current Scope" note on Why Adopt V2 for the canonical statement that a customer-applied HSA designation "does not change a card into the separate HSA payment-method type" — don't restate or paraphrase that rule here; link to it.
  • Cross-version compatibility (cross_version.enabled, see Backward Compatibility) is relevant only for merchants migrating from V1 — it has no effect for a net-new merchant, since compatibility routing depends on detecting V1-origin records that a net-new merchant will never have.

To enable Split tender future​

  • Enable split tender future : splitTender

Configure Split tender Reference​

TypeDescriptionDefault
enabledFlag to enable split tender for the merchantFalse

Customer authentication logic​

  • Customer authentication stratergy is determined by : authenticationStrategy
  • Possible value for authenticationStrategy is "IDP_NOT_REQUIRED" or "IDP_REQUIRED"

Customer authentication Types reference​

TypeDescriptionDefault
IDP_NOT_REQUIREDCustomer already authenticated before session creationYes
IDP_REQUIREDCustomer needs to be authenticated by a third-party system after session creation to identify the customerNo
🔒 InternalInternal information — not visible in the public (merchant) site.

Best Practices​

  • Double-check all required fields before submitting onboarding requests.
  • Use the checklist to ensure no step is missed.
  • Store sensitive information securely and comply with data privacy regulations.
  • Review webhook configuration and reporting options for full integration.

Troubleshooting & Support​

For further assistance, contact the support team or refer to the Developer Documentation.