🚀 Studio 2.1 Is Here! Smarter Insights with UTM Tracking & Analytics

Need Help? Let's Find the
Answer Together!

Sorry, we didn't find any relevant articles for you.

Send us your queries using the form below and we will get back to you with a solution.

Custom Fields

Topics on Custom Fields

How do the Like/Like field relationships work in Payments2Us?

A feature in Payment2Us is that some objects where if a custom field is created o ...

A feature in Payment2Us is that some objects where if a custom field is created on those objects with the same APi name, then they will populate the value in one to the other. The names (labels) of the fields don't have to match, but the APi names need to match exactly.

The Payment Txn object supports copying like for like fields to:

  • Contact
  • Account
  • Opportunity
  • Campaign Member
  • Recurring Payments*

If a Checkout Form is used with a URL Token, then like for like fields from the URL Token object are copied to:

  • Payment Txn

For Recurring Payments, like for like fields are copied from the Contact object are copied to:

  • Payment Txn

For example: A field with the API name Favourite__c on both the Payment Txn and Contact, any value in the Payment Txn field will update the same information onto the contact field.

Things to be aware of when using this feature:

  • Payments2Us managed fields have the APi naming convention of AAkPay at the start of the field names eg: AAkPay__custom__c which is not included when the feature is identifying APi names. Eg: It will consider AAkPay__custom__c to be the same APi name as custom__c. Be aware when creating custom APi names as they can be unintentionally named the same as the managed fields. This can also cause errors to occur.
  • Restricted Picklist values must match the values it is trying to update, otherwise Payment Txns will error.
  • Like/Like fields don't have to be the same field type e.g.: text, picklist etc, but it is recommended that they are.
  • The "Override Target Contact Values" field on the Merchant Facility needs to be set to YES in order for like to like fields to be applied.
  • It is recommended the "Batch Processor" on the Merchant Facility be started.
 

Notes:

  • Only for custom fields added in your instance of Salesforce.  Field that are part of Payments2Us package are selectively updated by code in the matching process.
  • The target field will ONLY be updated, if the Field Level Security allows for this.  When the Batch Processor is running, the user that started the Batch Processor is the context that is used for Field Level Security.
  • For Checkbox fields, these will untick the target field if the Checkbox is NOT selected.
  • Like to Like fields can be used to auto-populate custom fields for payments processed through internal forms.
 

 

I've added some values to an existing picklist. They are visible, but when I try and select them, it comes back with a "bad value" error. Why can't I select this value?

When a picklist is created, the user is given the option to add the values to all ...

When a picklist is created, the user is given the option to add the values to all or particular record types in a single step during the creation process. When values are added after the fact, values need to be added to the desired record types. They might be visible, but the will not be able to be selected unless they've been added as available to that record type.

  1. Go to Setup>Object Manager, and select the object the field is part of.
  2. On the left hand menu in the Object, select Record Types.
  3. In the record type(s) find the field the new values have been added to. Click Edit next to the field name.
  4. Move them to the selected column on the right.

Do the web forms support all field types?

Unfortunately, multi-picklists fields, dependant pick lists and look-up fields ar ...

Unfortunately, multi-picklists fields, dependant pick lists and look-up fields are not supported on the web forms.

NOTE: Formula fields are only available on Complete Page. Should you need formula fields on the input page, as a work around - you may add (text/date) field - mark as read only using payment form builder, apply default value. Vs. Formula field on input page.

Can we use related object fields on the Payment Txn field-sets?

For any of our field sets, please never use the related object. E.g when the "> ...

For any of our field sets, please never use the related object. E.g when the ">" symbol appears. What you need to do is create a custom field on the Payment Txn that has the same API name as that on the contact.

Then make the field publicly accessible. Steps to be followed: How to add custom fields on a web form 

How to I pass values to Checkout Form custom fields using URL Parameters customField[1...10]Name / customField[1...10]Value?

The Checkout Form allows you to populate custom field values using URL Parameters ...

The Checkout Form allows you to populate custom field values using URL Parameters.

Before you can populate a custom field on the form, you first need to use Salesforce Object Manager to Add the field to the Payment Txn Object, then make it Publicly Visible and then you can use the Payment Form Builder to add the custom field to the Checkout Form.

The ability to pass in values to a custom field is ONLY available to custom fields that your organisations has added to the Payment Txn. It cannot be used to update any of the Payments2Us Managed Package fields.

There is a possibility of 10 custom fields that can be populated. The [1...10] represents Custom Field 1, Custom Field 2, Custom Field 3.... all the way through to Custom Field 10.

The customField[1..10]Name is used to pass in the api name of the custom field you wish to update.

The customField[1..10]Value is used to pass in the value for the field that you wish to update.

If you have a custom picklist field called with an API name of make__c and a second custom field with an API name of model___c, you could use the URL Parameters below to pass in "Toyota" as the make and "Corolla" as the model.

..../AAkPay__checkoutM?customField1Name=make__c&customField1Value=Toyota&customField2Name=model__c&customField2Value=Corolla

If the field you are trying to update is a Date field type, the format of the value passed in must be in your local format. See examples in the Apex Date Class Parse documentation.

If the field you are trying to update is a DateTime field type, the format of the value passed in must be in your local format. See examples in the Apex DateTime Class Parse documentation.

How to auto-populate custom fields for payments processed through internal forms?

You can set up Like-to-Like field relationships in Payments2Us, which automatical ...

You can set up Like-to-Like field relationships in Payments2Us, which automatically populates a custom field on a payment checkout form with the value from a matching field on the related object record (Contact, Account or Opportunities). This works when the custom fields on both, the Related object and Payment Txn object have the exact same API Name.

To set this up, follow these steps:

Once these steps are complete, the custom field's value will automatically populate for that particular form when a payment is initiated Internally. Such as through Make a Payment button on the related object record page. 

What is the "Override Target Contact Values" option on Merchant Facility?

Overview When a payment, donation, or membership renewal form is submitted, Payme ...

Overview

When a payment, donation, or membership renewal form is submitted, Payments2Us may update existing Salesforce Contact records with information from that transaction (for example, address, phone, or email details).

The Override Target Contact Values setting controls how Payments2Us handles these updates — specifically, whether it should overwrite existing Contact data or only fill in blank fields.

 

How it works

When Enabled

  • Payments2Us overwrites existing Contact field values with data coming from the latest transaction form.
  • This ensures that new or updated details provided by a payer (for example, a new phone number or address) are reflected directly in Salesforce.
  • Note: if older data is stored on the renewal record, that older data may overwrite the clean data currently on the Contact.

When Disabled

  • Payments2Us will only populate blank Contact fields.
  • It will not overwrite any existing values already stored on the Contact record.
  • This option helps prevent unwanted updates or data loss when processing renewals or automated transactions.

 

Typical use cases

Scenario Recommended setting Notes
Membership renewals or recurring payments Disabled Prevents overwriting existing, verified Contact data during automated renewals.
Donation or payment forms where supporters update their details Enabled Allows new data entered through forms to automatically sync into Salesforce.
Organisations with strict CRM data integrity rules Disabled Ensures Salesforce remains the single source of truth for Contact information.

 

Where to find the setting

  1. Go to Setup → Payments2Us → Merchant Facilities.
  2. Open the Merchant Facility record used for your payment processing or renewals.
  3. Locate the checkbox labeled Override Target Contact Values.
  4. Interpretation:
    • Checked (Yes) — Overwrites Contact data with transaction data.
    • Unchecked (No) — Updates only blank Contact fields.
Testing tip: If you’re unsure why this was enabled, test the change in a sandbox first. Disable the checkbox in sandbox and run a renewal test to confirm existing Contact data remains unchanged while blank fields still populate.

 

If your organisation uses Like-for-Like field relationships, note the following:

  • The Override Target Contact Values field on the Merchant Facility must be set to Yes for Like-for-Like updates to be applied.

See: How do the Like-for-Like field relationships work in Payments2Us?

 

Summary

Enabled Overwrites existing Contact fields with the latest transaction data.
Disabled Only fills blank fields; existing values remain unchanged.
Best practice Test changes in sandbox before applying to production. Review any automations or integrations that may also write to Contact fields.

 

Further tips

  • If unexpected Contact overwrites occur, review both the Merchant Facility configuration and any Flows, Apex, integrations, or managed packages that may modify Contact data.
  • If you need help reviewing your configuration or testing in sandbox, contact support(at)payments2us.com and include your Merchant Facility name and a description of your test steps and results.
     

How the "Override Target Contact Values" setting affects the "Membership No." field

Overview When members pay or renew their dues through Payments2Us forms, the syst ...

Overview

When members pay or renew their dues through Payments2Us forms, the system links each transaction to a Contact record and assigns (or reuses) a Membership No. on that Contact. The behavior of this assignment depends on whether Override Target Contact Values is enabled on the Merchant Facility being used.

 

How it works

When Override Target Contact Values = YES

  • Payments2Us updates existing Contacts with data from the new transaction, including the Membership No. field if applicable.
  • If the Contact already has a Membership No., Payments2Us reuses that number for the new transaction.
  • If the Contact is new or has no existing Membership No., the system assigns a new number (using the Membership Next No. sequence).

When Override Target Contact Values = NO

  • Payments2Us does not overwrite existing Contact data.
  • If a transaction is processed for an existing Contact, the system treats it as a new membership and assigns a new Membership No. — even if one already exists on that Contact.
  • This can lead to multiple Membership Nos. across transactions for the same person.

When Override Target Contact Values = NONE

  • The system behaves similarly to the YES setting in this specific case for membership assignment.
  • Existing Contacts keep their current Membership No., and the system reuses that number for subsequent transactions.

 

Example Scenarios

In testing, six scenarios were evaluated:

  • Existing Contact – Override = YES
  • Existing Contact – Override = NONE
  • Non-existing Contact – Override = NONE
  • Non-existing Contact – Override = NO
  • Existing Contact – Override = NO
  • Non-existing Contact – Override = YES

Results:

  • For all cases, the system assigned a Membership No..
  • For cases where Override = YES or NONE, existing Contacts retained their current Membership No.
  • For cases where Override = NO, new Membership Nos. were generated — even for existing Contacts.

 

What to do if "Override Target Contact Values" was previously off

If the setting was previously set to NO before being turned to YES:

  • Past transactions may have generated new Membership Nos. instead of reusing existing ones.
  • These Contacts may now have duplicate or inconsistent Membership numbers across transactions.

To correct this:

  1. Run a report on past membership transactions to identify records with incorrect or missing Membership Nos.
  2. Compare these with earlier transactions for the same Contacts to determine their correct Membership No.
  3. Manually update those Contact records to reflect the proper Membership No.
  4. Once the Override Target Contact Values setting is enabled, future transactions will automatically reuse the correct number.

 

Best Practice

  • Keep Override Target Contact Values enabled on the Merchant Facility if you want consistent reuse of existing Membership Nos. during renewals or repeated payments.
  • Disable only if you intentionally want to generate new membership numbers for every payment (which is uncommon).
  • Always test configuration changes in a sandbox environment before applying them to production.

 

Example Configuration

  1. Go to Setup → Payments2Us → Merchant Facilities.
  2. Open the Merchant Facility used for membership payments.
  3. Locate the Override Target Contact Values checkbox and ensure it is checked.
  4. Save the changes and test a membership renewal or new signup to confirm Membership No. assignment works as expected.

 

Summary

Setting Behavior
YES Reuses existing Membership No. for existing Contacts. Assigns a new number for new Contacts.
NO Creates a new Membership No. even for existing Contacts.
NONE Same as YES — reuses existing Membership No. where applicable.

 

Troubleshooting and next steps

  • If Membership Nos. were not assigned during past payments, confirm the Override Target Contact Values setting on your Merchant Facility at the time of those transactions.
  • Use Salesforce reports to identify Contacts missing their Membership No. and manually update them using the previous transaction data as reference.
  • After enabling the setting, all future payments will automatically align Membership Nos. correctly.

Â