## Objects, record types and fields
Salesforce objects (sObjects) are stored as records in the Salesforce database. These records are persistent representations of data.
Some API resources accept, or even require, sObjects. The Payer block, for example, requires sObjects such as Contact and Account.
The API allows you to define these objects in payloads. FinDock sObjects like Inbound Report can be included as well,
but they require you to specify the object fields as Salesforce fields.
**Record types** let Salesforce administrators offer specific business processes, picklist values, and page layouts to different users.
Organizations can, for example, differentiate between `Account` object records by assigning them an `Organization` or `Household` record type.
This facilitates the application of different types of page layouts or possible field values based on what record type an `Account` is.
**Fields** are defined at the object level in Salesforce. Next to the out-of-the-box fields from Salesforce, custom fields can be added to objects.
Use the Object Manager in Salesforce Setup to see available fields. Implementations of Salesforce can use different fields for a value like `email`.
Custom fields for *standard Salesforce objects* like `Contact` and `Account` are passed with "__c" at the end of the field name.
In the example below, you see the standard fields `FirstName` and `LastName` and a custom field `TwitterHandle` for the Contact object.

```json
{
  "Payer":{
    "Contact":{
      "SalesforceFields":{
            "FirstName":"Test",
            "LastName":"Payer",
            "TwitterHandle__c": "@TestPayerFamily"
        }
    }
  }
}
```
Custom fields for **custom FinDock objects** like `Installment` and `Recurring Payment` can also be passed in a `SalesforceFields` object. `SalesforceFields`
passed in the `OneTime` object are copied to the `Installment` record in Salesforce and `SalesforceFields` passed in the `Recurring` object are copied to the
`Recurring` object in Salesforce. To which `Recurring` object the values are stored depends on the FinDock configuration.

```json
    {
      "OneTime":{
        "Amount": 10.0,
        "SalesforceFields": {
          "Sales_Invoice__c": "a506E0000009TfL"
        }
      }
    }
    ```

## Working with payer details

Salesforce provides two objects to define the Payer:
  - Account: usually an organization
  - Contact: an individual

Added to that simple split is [Person Account](https://help.salesforce.com/s/articleView?id=sf.account_person.htm&type=5), which
stores information about individual people by combining certain Account and Contact fields into a single record. It is not its
own object, but can be stored as an Account with a specific record type (see below).

Some features of Salesforce - like Fundraising used in NonProfit Cloud (NPC) - *require* Person Account. The payer details are a Person Account
record rather than a Contact. Make sure to always check with your Salesforce admin whether they are enabled and used.

To send Person Account details to the Payment API, use an Account object with a `RecordTypeName` (API name) of the type Person Account.
By default the API name is `PersonAccount`, but there can be customized or the org (Salesforce environment may have multiple
Person Account record types. Always consult your Salesforce admin regarding record types.

Whether an Account or Contact record, you always need to take into consideration how the payer is deduplicated. Every organization 
has [configured deduplication rules](https://help.salesforce.com/s/articleView?id=sales.managing_duplicates_overview.htm&type=5)
that define the information the payment intent message needs to include for deduplication, bearing in mind that the more data points you 
have, the more effective deduplication is.

```json
{
  "Account":{
    "RecordTypeName": "person-account-record-type",
        "SalesforceFields":{
          "Name":"Test Payer",
          "BillingStreet":"Any Street",
          "BillingCity":"Any City",
          "BillingPostalCode":"00000"
        }
      }
}
```
For Person Accounts the following exceptions for (custom) field notations apply:
- Standard Account fields can be passed as regular fields: `"BillingStreet":"Any Street"`.
- Custom Account fields can be passed with the regular `__c` suffix: `"Custom_Street__c":"Any Street"`.
- Standard Contact fields need to be prefixed with `Person`, with the exception of FirstName, LastName, Salutation which are passed as regular fields: `"PersonEmail" : "test@findock.com"`.
- Custom Contact fields need to be suffixed with `__pc`: `"Custom_email__pc":"test@findock.com"`


```json
{
  "Account":{
    "RecordTypeName": "person-account-record-type",
    "SalesforceFields":{
      "FirstName": "John",
      "LastName": "Payer",
      "PersonEmail": "test@findock.com",
      "BillingStreet": "Any Street",
      "Custom_account_field__c": "Apartment Name",
      "Custom_contact_field__pc": "Middle Name"
    }
  }
}
```
For the FinDock for Fundraising source connector used with NonProfit Cloud (NPC), for example, the following exception applies:
Since the "Recurring" object (Gift Commitment) is split in two objects (Gift Commitment & Gift Commitment Schedule), a prefix `GiftCommitment` is required to set SalesforceFields on this object.
Fields without prefix are assumed to be set on the Gift Commitment Schedule object. Example: `GiftCommitment.GiftVehicle`.
You can check which Source Connectors are available by performing a GET operation on the [Source Connector](/api/payment-api-v2/source-connectors) endpoint.