Punchout Settings and Configuration Guide

Note: Many punchout behaviors can be customized through both settings and interceptors. When deciding whether to use a setting or an interceptor, consider:
• Use settings for configuration options that might need to change per environment or customer, without requiring code changes
• Use interceptors for complex logic or transformations that can't be achieved through simple configuration values

punchOutDomainForNonEmailUsernames
Purpose: Specifies the domain to append to usernames that are not in email format when processing punchout requests.
Default: "kodaris.com"
Example: If a punchout request includes a username "john" and this setting is "example.com", the system will treat the username as "john@example.com".
When to modify: Change this if you need to standardize non-email usernames to a specific domain.

punchOutPrimaryUserIdentitySource
Purpose: Controls the priority of identity headers (From or Sender) when extracting user identity from punchout requests.
Values: "FROM" or "SENDER"
Default: "FROM"
When to modify: Some punchout providers may place the actual user identity in the Sender element rather than the From element. Change this setting if user authentication is failing and you need to prioritize a different identity source.

punchOutIsContactEmailPerShipTo
Purpose: When enabled, the system prepends the ShipTo code to the user's email to create unique usernames per shipping location.
Values: true/false
Default: false
Example: If set to true and a user "john@example.com" punches out with ShipTo code "123", the system will use "123-john@example.com" as the username.
When to modify: Enable this when customers need separate accounts per shipping location to control catalog access or pricing.

punchOutOrderRequestXSLT
Purpose: Defines an XSLT transformation to apply to incoming PunchOutOrderRequest XML messages.
Default: null (no transformation)
Configuration: This is a company-specific setting, not a system-wide setting.
When to modify: Set this when you need to transform the XML format of incoming order requests to match your system's expected format.
Note: This can be useful for supporting non-standard cXML implementations without requiring code changes.

punchOutRedirectURIForEditOperation
Purpose: Specifies the URI to redirect customers to after login for "edit" operations.
Default: "/cart" (redirects to cart page)
When to modify: Change if you want "edit" operations to redirect to a different page after authentication.

punchoutAllowPunchOutAuthenticationInterceptor
Purpose: Enables or disables the punchout authentication interceptor for dynamic user selection.
Values: true/false
Default: false
When to modify: Enable this if you need to implement custom authentication logic, such as mapping users based on ShipTo address IDs as shown in the example interceptors.
Note: This must be enabled by Kodaris support as mentioned in the punchOutAuthentication.js interceptor.

punchoutRedirectUrl
Purpose: Custom redirect URL to use after authentication for a specific company.
Default: null (uses system default)
Example: "https://example.com/special-landing-page"
When to modify: Set this when a specific company needs a custom landing page after punchout authentication.
Note: This setting was found in the punchOutSetupRequestSuccessResponse.js interceptor.

Domain Identity and Shared Secret
Purpose: Authentication credentials for punchout integration.
Configuration: Set up in the Company > More > Add Punchout Customer in the admin portal.
When to modify: When setting up a new punchout integration or updating credentials.

Security Consideration: Shared secrets should be treated as sensitive information.