Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ptp 1321 apple sdk #96

Merged
merged 17 commits into from
Oct 15, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
110 changes: 96 additions & 14 deletions docs/api/merchant.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,20 +27,20 @@ Merchants are the entities that are using Pay Theory to accept payments.
}
```

| Key | type | description |
|----------------------|------------------|---------------------------------------------------------------------------------------------------------------------|
| ach_active | Boolean | If the merchant has successfully completed onboarding and has an ACH processor active. |
| api_key | String | The API key of the merchant. This is used to authenticate use of the PayTheory Web and Native SDKs. |
| card_active | Boolean | If the merchant has successfully completed onboarding and has a card processor active. |
| cash_active | Boolean | If the merchant has successfully completed onboarding and has a cash processor active. |
| country_code | String | The country code of the country the merchant operates from. |
| fee_matrix | FeeMatrix | The fee matrix that the merchant is using. This is used to calculate the fees that are charged to the payor. |
| is_system | Boolean | If the merchant is a system merchant. System merchants are merchants that also have sub merchants. |
| merchant_name | String | The name of the merchant. |
| merchant_uid | String | The Pay Theory unique identifier assigned to the merchant. |
| parent_merchant_uid | String | The `merchant_uid` of the parent merchant. This is only set if the merchant is a sub merchant of a system merchant. |
| settings | MerchantSettings | The settings that the merchant has set. |
| submitted_onboarding | Boolean | Whether the merchant has submitted their onboarding information. |
| Key | type | description |
|----------------------|---------------------------------------------|---------------------------------------------------------------------------------------------------------------------|
| ach_active | Boolean | If the merchant has successfully completed onboarding and has an ACH processor active. |
| api_key | String | The API key of the merchant. This is used to authenticate use of the PayTheory Web and Native SDKs. |
| card_active | Boolean | If the merchant has successfully completed onboarding and has a card processor active. |
| cash_active | Boolean | If the merchant has successfully completed onboarding and has a cash processor active. |
| country_code | String | The country code of the country the merchant operates from. |
| fee_matrix | FeeMatrix | The fee matrix that the merchant is using. This is used to calculate the fees that are charged to the payor. |
| is_system | Boolean | If the merchant is a system merchant. System merchants are merchants that also have sub merchants. |
| merchant_name | String | The name of the merchant. |
| merchant_uid | String | The Pay Theory unique identifier assigned to the merchant. |
| parent_merchant_uid | String | The `merchant_uid` of the parent merchant. This is only set if the merchant is a sub merchant of a system merchant. |
| settings | [MerchantSettings](#merchantsettingsobject) | The settings that the merchant has set. |
| submitted_onboarding | Boolean | Whether the merchant has submitted their onboarding information. |

### The Fee Matrix Object

Expand Down Expand Up @@ -146,6 +146,33 @@ type CardServiceFee {
|max_fee |Int | The maximum fee that will be charged to the merchant for each transaction. |
|min_fee |Int | The minimum fee that will be charged to the merchant for each transaction. |

### Merchant Settings Object

```js
{
contact_email: AWSEmail
contact_phone: AWSPhone
facebook: AWSURL
instagram: AWSURL
linkedin: AWSURL
tiktok: AWSURL
twitter: AWSURL
website: AWSURL
}
```

| Key | Type | Description |
|-----|------|-------------|
| contact_email | AWSEmail | The contact email for the merchant. |
| contact_phone | AWSPhone | The contact phone number for the merchant. |
| facebook | AWSURL | The Facebook URL for the merchant. |
| instagram | AWSURL | The Instagram URL for the merchant. |
| linkedin | AWSURL | The LinkedIn URL for the merchant. |
| tiktok | AWSURL | The TikTok URL for the merchant. |
| twitter | AWSURL | The Twitter URL for the merchant. |
| website | AWSURL | The website URL for the merchant. |


***
## Query Merchant
```js
Expand Down Expand Up @@ -455,3 +482,58 @@ input CardServiceFeeInput {
}
}
```

## Update Merchant Settings
Srinithya-Indla marked this conversation as resolved.
Show resolved Hide resolved

```graphql
mutation {
updateMerchantSettings(
merchant_uid: ID!,
settings: MerchantSettingsInput!
) {
Boolean
}
}
```

**Parameters**

| Key | Type | Description |
|-----|------|-------------|
| merchant_uid | ID! | The unique identifier of the merchant whose settings are being updated. |
| settings | MerchantSettingsInput! | The new settings for the merchant. |

**MerchantSettingsInput Object**
Srinithya-Indla marked this conversation as resolved.
Show resolved Hide resolved

```graphql
input MerchantSettingsInput {
contact_email: AWSEmail
contact_phone: AWSPhone
facebook: AWSURL
instagram: AWSURL
linkedin: AWSURL
tiktok: AWSURL
twitter: AWSURL
website: AWSURL
}
```

All fields in the MerchantSettingsInput are optional. If a field is not provided, it will not be updated.

:::note Important
The `AWSEmail`, `AWSPhone`, and `AWSURL` types must be valid according to AWS AppSync's validation rules. If an invalid email or phone number is provided, the mutation will throw an error. For details on how these types are validated, please refer to the [AWS AppSync Scalar Types documentation](https://docs.aws.amazon.com/appsync/latest/devguide/scalars.html).
:::

**Returns**

```js
{
"data": {
"updateMerchantSettings": true
}
}
```

| Key | Type | Description |
|-----|------|-------------|
| updateMerchantSettings | Boolean | Returns true if the update was successful, false otherwise. |
47 changes: 47 additions & 0 deletions docs/main/changelog.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
sidebar_position: 6
sidebar_label: 'Changelog'
title: "Changelog"
---

# Changelog
Additions and updates to Pay Theory’s API

## October 4, 2024
#### Added to API
* `country_code` was added to the Merchant and ListMerchant object
* `canadian_eft` was added to the PaymentMethodInput for creating Canadian Bank accounts
* `issuing_country_code` was added to the PaymentMethodToken schema
* `flag_for_review` key added to Transaction schema

***

## September 29, 2024
#### Added to API
* `country_code` was added to the Merchant and ListMerchant object
* `canadian_eft` was added to the PaymentMethodInput for creating Canadian Bank accounts
* `issuing_country_code` was added to the PaymentMethodToken schema
* `flag_for_review` key added to Transaction schema
* `merchant` object of type ListMerchant was added to the Transaction schema
* `updateTransactionInReview` mutation added to allow someone to approve or decline flagged transactions
* `one_time_use_token` added to the createTransaction mutation to make it so that we immediately disable token after making the transaction
* `createReversal` mutation added to API. Returns object with `is_void` and `transaction_id` in the response so you can tell if a payment was refunded, voided, or partially voided
* `barcode` query added to API so you can fetch a single cash barcode from our system
* `createBarcode` mutation added to API allowing cash barcodes to be created directly in the API without use of the SDK
#### Added to JS SDK
* `country` added to the payTheoryFields function to tell the SDK what fields to look for when initializing the Bank Fields. Defaults to USA but also accepts CAN
* `oneTimeUseToken` added to the transact function parameters to make it so that we immediately disable token after making the transaction
* New div IDs added for initializing the CAN bank fields:
* bank-account-number - `pay-theory-bank-account-number`
* bank-account-name - `pay-theory-bank-account-name`
* bank-account-type - `pay-theory-bank-account-type`
* bank-institution-number - `pay-theory-bank-institution-number`
* bank-transit-number - `pay-theory-bank-transit-number`
#### Changed
* `avs_status` now included in the Authorization and Transaction schema
* `bank_account_type`, `bank_code`, `barcode_id`, and `card_type` now included in the PaymentMethodToken schema
* CardType enum with the following types added to schema: `BUSINESS_CREDIT`, `BUSINESS_DEBIT`, `CREDIT_CARD`, `DEBIT_CARD`, `PREPAID_CARD`
* `void_amount` argument is deprecated in the `createVoidForAuthorization` mutation as only full voids are supported
* `createRefund` mutation is deprecated. Recommend using `createReversal` call now
* All successful transactions from the SDK/API will now have the state/status of `PENDING` instead of the potential of both `PENDING` or `SUCCEEDED`
* `PENDING` transactions are now able to be voided to prevent funds from moving before settle
4 changes: 2 additions & 2 deletions docs/main/recurring_payments/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -22,12 +22,12 @@ You will need to be able to tokenize a payment in order to set up a recurring pa
## Payment plans
Payment plans are recurring payments that will trigger on an interval and continue until a total amount is reached.

<a href= "../recurring_payments/create_a_payment_plan" class="button button--primary button--md">Create a payment plan</a>
<a style={{marginTop:'-1rem'}} href= "../recurring_payments/create_a_payment_plan" class="button button--primary button--md">Create a payment plan</a>

## Subscriptions
A payment subscription involves paying for ongoing use of a service or product. This payment will continue for as long as specified.

<a href= "../recurring_payments/create_a_subscription" class="button button--primary button--md">Create a subscription</a>
<a style={{marginTop:'-1rem'}} href= "../recurring_payments/create_a_subscription" class="button button--primary button--md">Create a subscription</a>



Expand Down
15 changes: 8 additions & 7 deletions docs/main/testing.mdx
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
sidebar_position: 6
sidebar_position: 7
sidebar_label: 'Testing'
title: "Testing"
---
Expand All @@ -8,7 +8,7 @@ title: "Testing"
This guide will show you how to test card and ACH payments, card failures and disputes.

:::danger Before you start
In order to test a payment method you need be set up to accept online payments.
In order to test a payment method you need be set up to accept online payments.

<a href= "getting_started/Quickstart" class="button button--primary button--md">Accepting Online Payments</a>
:::
Expand All @@ -21,7 +21,7 @@ When testing you will be using an SDK import and API Key that contains either pa

### Card Brands
|Card Brand |Testing Number |
------------|----------------------|
------------|----------------------|
|Discover |6542 1548 4662 3459 |
|Mastercard |5454 5454 5454 5454 |
|Amex |3434 343434 34343 |
Expand All @@ -32,7 +32,7 @@ To trigger certain failures process a payment using the following amounts. These


|Amount |Error Type |
------------|---------------------------------------|
------------|---------------------------------------|
|102 |GENERIC_DECLINE |
|193 |INSUFFICIENT_FUNDS |
|194 |INVALID_ACCOUNT_NUMBER |
Expand All @@ -48,8 +48,9 @@ If you want to trigger a dispute in sandbox, run a transaction for `888888`. You


## Testing ACH Transactions
|Name on Account |Account Number | Routing Number |
--------------------|--------------------|--------------------|
|Any |789456124 |789456124 |
| Transaction Outcome | Account Number | Routing Number |
|---------------------|----------------|----------------|
| Success | 0000000016 | 122105278 |
| Failure | 0000000005 | 122105278 |


128 changes: 128 additions & 0 deletions docs/sdk/apple/app_registration.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
---
sidebar_position: 7
sidebar_label: 'Register Your App'
title: "Register Your App"
---

# Apple App Attestation Setup Guide

## Introduction

Apple's App Attestation is a crucial security feature that verifies the authenticity of your app. When integrating with the Pay Theory SDK, it's important to understand how App Attestation is used in different environments:

- **Production Environment**: App Attestation is required for all apps in the production environment. You must complete the setup process described in this guide to ensure your app can successfully go through Apple's App Attestation.

- **Sandbox Environment**: While App Attestation is not strictly required in the sandbox environment, it's highly recommended to test it to ensure a smooth transition to production. You can test App Attestation in the sandbox by following these steps:
1. Complete the setup process described in this guide.
2. When initializing the PayTheory object in your app, do not set `devMode` to `true`. For example:
```swift
let payTheory = PayTheory(apiKey: "your-sandbox-api-key")
```
3. This allows you to test App Attestation in the sandbox environment, mimicking the production behavior.

:::note DevMode
Setting `devMode` to `true` bypasses App Attestation, which is useful for testing in simulators but does not reflect the production environment. Always test with `devMode` set to `false` in sandbox before moving to production.
:::

By testing App Attestation in the sandbox environment, you can identify and resolve any issues before deploying to production, ensuring a smoother launch process.

Now, let's proceed with obtaining the necessary credentials for Apple's App Attestation.

## Obtaining the Necessary Credentials

To set up Apple's App Attestation, you'll need to obtain the following:

1. App ID (composed of App ID Prefix and Bundle ID)
2. DeviceCheck Key
3. DeviceCheck Key ID

These credentials are essential for registering your app and enabling it to go through Apple's App Attestation process.

## 1. Obtaining the App ID

The App ID consists of two parts: the App ID Prefix and the Bundle ID. Here's how to obtain both:

1. Log in to your [Apple Developer Account](https://developer.apple.com/account/).
2. Navigate to "Certificates, Identifiers & Profiles".
3. In the sidebar, select "Identifiers" under the "Identifiers" section.
4. Look for your app in the list.

Here you'll find:
- The Bundle ID, typically in the format `com.yourcompany.yourappname`.
- The App ID Prefix, which is usually a 10-digit Team ID.

If you haven't created an App ID yet:

1. Click the "+" button to add a new identifier.
2. Select "App IDs" and click "Continue".
3. Choose "App" as the type and click "Continue".
4. Fill in the description and Bundle ID.
5. Select the capabilities your app needs. *(App Attest is required for Pay Theory SDK integration.)*
6. Click "Continue" and then "Register" to create the App ID.

After registration, you'll be able to see both the App ID Prefix and Bundle ID for your app.

## 2. Creating a DeviceCheck Key

The DeviceCheck Key is used to authenticate your server with Apple's servers.

1. Still in the "Certificates, Identifiers & Profiles" section, click on "Keys" in the sidebar.
2. Click the "+" button to add a new key.
3. Give your key a name (e.g., "DeviceCheck Key for MyApp").
4. Under "Key Services", check the box next to "DeviceCheck".
5. Click "Continue" and then "Register".
6. On the next screen, click "Download" to save your private key.
:::warning Warning
This is your only chance to download the key. Store it securely!
:::
7. Click "Done".

## 3. Obtaining the DeviceCheck Key ID

The Key ID is a unique identifier for your DeviceCheck Key.

1. After creating the key, you'll be taken back to the "Keys" page.
2. Find your newly created DeviceCheck Key in the list.
3. The "Key ID" column shows your DeviceCheck Key ID.

## Using the Credentials

Now that you have obtained the necessary information:

1. App ID Prefix (e.g., `A1B2C3D4E5`)
2. Bundle ID (e.g., `com.yourcompany.yourappname`)
3. DeviceCheck Key (the `.p8` file you downloaded)
4. DeviceCheck Key ID (e.g., `YYX4DR48M7`)

You'll need to add these details to Pay Theory's system through the portal. Here's how:

1. Log in to your Pay Theory account portal.
2. Navigate to the Settings section.
3. Look for an option related to "Apple App Details" or "iOS App Configuration".
4. You should see fields to enter your App ID, Device Check Key, and Device Check Key ID.
5. For the App ID field, enter the information in this format: `{App ID Prefix}.{Bundle ID}`
For example: `A1B2C3D4E5.com.yourcompany.yourappname`
6. Enter the DeviceCheck Key and DeviceCheck Key ID as instructed previously.

:::important Key Format
When entering the DeviceCheck Key, make sure to copy and paste the **entire** contents of the `.p8` file, including the header and footer lines:
```
-----BEGIN PRIVATE KEY-----
[... key content ...]
-----END PRIVATE KEY-----
```
Omitting these lines will result in an invalid key and authentication failures.
:::

6. Save your changes.

By adding these credentials to the Pay Theory portal, you're enabling the system to properly authenticate and verify your app during the App Attestation process.

## Next Steps

1. Ensure your app is properly configured to use App Attestation.
2. Test your app thoroughly in the sandbox environment.
3. When ready, transition to the production environment.
4. Keep your credentials secure and up to date in the Pay Theory portal.

For any additional assistance or questions about integrating these credentials with Pay Theory, please refer to the Pay Theory documentation or contact their support team.
Loading
Loading