PayID Activation

Merchant Steps (Front-End)

The Allow PayID Self Service Setting will be ON by default in the merchant settings on their account. This means that merchants can initiate PayID activation directly within their account. 

They will:

• Navigate to Settings > Configure Payments
• Locate the PayID section and select Activate PayID

If required information is missing, the system will prompt the merchant to update their details via the Business Details section of their account.
This may include items such as:

• Business contact information
• Business website
• Director information

The platform will clearly outline what is missing and guide the merchant to complete these fields.

Once updated, the merchant must return to the Configure Payments page and re-attempt activation.

The merchant will then:

• Select their PayID configuration:
  • Customer Reference (default – recommended for most merchants)
  • External ID (recommended for but not limited to API users)
• Submit the request

At this point, the PayID status will move to Pending while registration is processed (typically up to 3 business days).

Post-Activation

Once PayID has been successfully enabled:

• The merchant will receive an in-app notification confirming activation
• PayID can then be toggled on/off within:
  • Payment Portal
  • Xero invoices

PayID will automatically appear as a payment option for customers when enabled.

Notes for Support

• Ensure merchants understand the Pending status and expected timeframes
• Most merchants should use Customer Reference configuration unless there is a specific requirement
• Escalate any delays beyond standard processing timeframes

Types of PayID Setups

Consistent PayIDs (Most Common)

Overview:
Each customer is assigned a consistent PayID that is reused over time, but only becomes active when a payment request is issued.

How it works:
When a customer is created, their PayID is automatically generated using a combination of their customer reference number (entered by the merchant) and their unique customer number, ensuring each PayID is unique to that customer.

If a customer reference number is not entered during setup, the system will automatically generate a unique code based on the payment request code or invoice code.

When a payment request is created, the customer’s PayID becomes active and is linked to that specific amount. The customer can use the same PayID each time they are asked to pay. Once the payment is completed, the PayID closes until the next request is created.

Key characteristics:

• Same PayID per customer (auto-generated based on customer reference + customer number)
• Automatically generates a reference if one is not provided
• Only active when a payment request exists
• Includes amount validation
• Automatically closes once payment is received

Customer experience:

• Customers can save the PayID in their banking app
• For future payments, they simply select the saved PayID and pay the requested amount
• No need to re-enter details each time

When to recommend:

• Most merchants (default option)
• Businesses with repeat customers
• Ongoing billing or ad-hoc invoicing
• Merchants wanting a balance between convenience and control

Why this is preferred:

• Reduces friction for repeat payments
• Ensures accurate payment matching
• Minimises reconciliation issues
• Keeps control over when payments can be made

Unique PayIDs

Overview:
A brand new PayID is generated for every individual transaction or payment request.

How it works:
Each time a payment request is created, the system generates a completely unique PayID. This PayID is linked to a specific transaction and exact payment amount. Once the payment is completed, the PayID automatically closes and cannot be used again.

Key characteristics:

• One-time use only
• Strict amount validation (must match exactly)
• Automatically closes after payment
• Cannot be reused or saved by the customer

When to recommend:

• Higher-risk industries or merchants with strict compliance requirements
• One-off or high-value transactions
• Merchants needing maximum control and payment accuracy
• Businesses sending multiple payment requests to the same customer for different amounts at the same time

Why this is preferred (in these scenarios):

• Ensures maximum accuracy and control over each transaction
• Eliminates the risk of incorrect or misallocated payments
• Ideal for handling multiple concurrent payment requests for a single customer
• Provides a clear audit trail, with each PayID tied to a specific transaction

Additional context:

For API-integrated merchants, it is generally recommended to use Consistent PayIDs configured with the External ID setting, rather than the default Customer Reference option. This allows for more flexibility when managing dynamic or complex payment flows.

While this setup is most commonly used by API merchants, it is not limited to them and can be enabled for other merchants where the use case requires it. 

Persistent PayIDs

Overview:
A permanently active PayID that customers can pay into at any time, without needing a payment request.

How it works:
The PayID remains open indefinitely and is not tied to a specific payment request or amount. Customers can send payments whenever they choose, similar to using a BPAY reference or standard bank transfer.

This means there is no requirement for the merchant to trigger or manage individual payment requests. The PayID is always available for use.

Key characteristics:

• Always active
• No automatic closure after payment
• No strict linkage to a specific request or amount
• Can be used repeatedly at any time

Customer experience:

• Customers can save the PayID in their banking app and use it whenever needed
• No need to wait for a payment request or link
• Ideal for quick, self-initiated payments
• Payments are still processed in real time with instant confirmation

When to recommend:

• Businesses that accept ad-hoc or flexible payments
• Situations where customers need to pay at any time without prompting
• Use cases similar to BPAY or open account payments
• Merchants who want to offer a simple “pay anytime” option

Why this is preferred (in these scenarios):

• Provides maximum flexibility for both the merchant and customer
• Removes the need to create and manage individual payment requests
• Ideal for businesses with less structured billing cycles
• Enables a more self-service payment experience for customers

Considerations:

• Less control over payment timing and amounts
• Payments are not tied to a specific request, so may require manual reconciliation
• Not ideal for businesses that require strict payment matching or scheduled billing

Support notes:

• This feature is not available to all merchants and may require eligibility review before being enabled
• We may look to implement a charge for this feature (TBA)
• Ensure merchants understand the trade-off between flexibility and control
• Best suited for simpler payment flows or where reconciliation processes are already in place