Card brands' requirements for their Stored Credential Transaction framework mandate the identification of both the initial storage and subsequent use of payment credentials.

Stax enables merchants to comply with these mandatory requirements, allowing them to benefit from the increased transaction approval rates and reduced decline ratios offered by the Stored Credential Transaction framework.

API Overview

Stax has implemented enhancements to the API to introduce additional flexibility and granularity when defining transaction characteristics. These updates are relevant for tracking and understanding transaction types within our systems. Any clients who have built to the Stax Charge API or the Stax Pay an Invoice API will be required to provide these property values to maintain compliance.

New Fields Introduced:

These properties are available and required for compliance in the request body for the POST/charge route as follows:

1. meta.transaction_initiation_type (required, string)

• Values: MIT or CIT
• Usage: This specifies whether a transaction is a Merchant-Initiated Transaction (MIT) or a Customer-Initiated Transaction (CIT).

2.[meta.transaction_schedule_type (required, string)

• Values: scheduled or unscheduled
• Usage: "Scheduled" denotes a recurring transaction or installment; "unscheduled" signifies a new payment not linked to any recurring schedule

Stax Scheduled Payments

Suppose you are using the Stax Scheduled Invoices APIs or Stax Pay Schedules within the portal for autopayments. In that case, the Stax system generates these payments, and therefore, no additional actions are required. The information provided here is purely for your knowledge.

One-Time Payments: If you are using the Stax Hosted Payments Page, Payment Links, or the StaxJS pay() method for one-time payments, all of these methods are customer-initiated and unscheduled. Stax’s system is populating the proper transaction characteristics, so no additional actions are required. The information provided here is purely for your knowledge.

Custom Schedules: If you opt to use your own schedule, please be aware of the following requirements:

• You will need to pass new data fields as specified when initiating Stax Payment requests through the Charge API to indicate that the payment is a scheduled payment.
• It's essential to correctly identify whether an invoice is a first-time or recurring transaction and whether the customer or the merchant initiated it to implement the use of Stored Credentials.

Understanding Customer Initiated Transactions (CIT) and Merchant Initiated Transactions (MIT)

Customer Initiated Transaction (CIT)

This transaction type happens when the customer actively participates in the checkout process. The primary characteristics include: Customer engagement: The customer must be actively involved, either physically in-store or through an online platform. Initiation of transaction: The customer starts the payment process by providing payment details.

Merchant Initiated Transaction (MIT)

This transaction type occurs when a merchant charges a customer’s payment method without the customer’s active involvement, provided the customer has given prior consent. Key aspects include:

• Pre-authorization: The customer has previously allowed the merchant to initiate transactions without being present.
• Dependency on previous CIT: An MIT generally follows a CIT, capturing the necessary authorization for future charges.

Initial Transaction (CIT):

Subsequent Transactions (MIT)

Use Cases

1. Customer Initiated (CIT) One-time Payment (Unscheduled)
   • The ISV builds its own hosted payments page where the customer (payer) can make a one-time payment.
   
   
   Example Request Payload

   {
   "transaction": {
   "payment_method_token": "exampleToken12345",
   "amount": 150,
   "currency_code": "USD",
   "meta": {
   "transaction_initiation_type": "CIT",
   "transaction_schedule_type": "unscheduled"
   			}
   		}
   }

2. Merchant Initiated (MIT) One-time Payment (Unscheduled)
   • The customer orders a product online and later adds accessories. Merchants can initiate this additional charge without requiring the customer to go through the payment process again.`

{
"transaction": {
"payment_method_token": "exampleToken12345",
"amount": 150,
"currency_code": "USD",
"meta": {
"transaction_initiation_type": "MIT",
"transaction_schedule_type": "unscheduled"
		}
	}
}`

3. Merchant Initiated (MIT) Scheduled Payment
   • An ISV provides a subscription service, and the merchant must charge customers for the subscription on a regular and automatic basis.

{
"transaction": {
"payment_method_token": "exampleToken12345",
"amount": 150,
"currency_code": "USD",
"meta": {
"transaction_initiation_type": "MIT",
"transaction_schedule_type": "scheduled"
		}
	}
}

4. The customer initiates the first transaction but also sets up a schedule for Recurring Payments.
   1. First Payment: CIT Unscheduled
      Example Request Payload

      {
      "transaction": {
      "payment_method_token": "exampleToken11223",
      "amount": 75,
      "currency_code": "USD",
      "meta": {
      "transaction_initiation_type": "CIT",
      "transaction_schedule_type": "unscheduled"
      		}
      	}
      }

   2. Future Payments: MIT Scheduled

{
"transaction": {
"payment_method_token": "exampleToken11223",
"amount": 75,
"currency_code": "USD",
"meta": {
"transaction_initiation_type": "MIT",
"transaction_schedule_type": "scheduled"
		}
	}
}