Recurring Payments

Our recurring payment product, PayPlan, lets you easily set up tokenized recurring billing.

Install the SDK in your IDE and set up your authentication.

You can make a given Payment Method the default with this example.

Use the following example to create a new subscription plan for a given payment method. The objects payPlanService and paymentMethod were defined above.

Failed status indicates the merchant should get new payment information from the customer.

You can get a list of all failed scheduled transactions from the night before by opting in to email notifications from PayPlan.

If a card exceeds retries with non-fatal decline codes, the schedule status changes to Failed. The payment status remains Active. Email notification is based on emailReceipt and emailAdvanceNotice.

Expired

There is logic in place for recurring billing. It allows us to drop the expiration date on a card if it is less than current MMYYYY and it’s a recurring billing transaction. By dropping the expiration date, the card can continue to be processed until eventually it is declined or and/or triggers a fatal error.

Declined

If a card is declined when processing a schedule, the “Failure Count” field is incremented. If the Failure Count exceeds the reprocessing count, then the schedule status is also updated to ‘Failed’. Each subsequent try is approximately 24 hours after.

If there is a communication failure, the schedule falls into an error queue and no updates are made.

We manually review schedules in the error queue on the next business day. Communication errors are exceptionally rare, so we typically don’t provide any information when they happen.

The following four codes are “fatal” response codes that you might receive from an issuer during schedule processing:

• Invalid
• Expired
• Lost/Stolen
• Revoked

These are the only response codes that can set the payment status to something other than Active/Inactive.

A one-time transaction doesn’t change the payment method status. The status only changes in certain cases. An example of this is when the issuer returns lost or stolen in a scheduled process. In this case the schedule status changes to failed and the payment status changes to Lost/Stolen.

If a card exceeds the allowed number of retries with non-fatal decline codes, the schedule status changes to Failed. But the payment status remains Active. The schedule can restart once the payment method is updated by the cardholder.

You can find payment methods associated using this method call.

You can find schedules associated using this method call.

Conditional parameters

Conditional parameters define which fields are editable depending on whether the schedule has started.

scheduleStarted returns True if at least one transaction in the schedule has processed, even if it has declined. The PHP-SDK will drop illegally passed fields during the edit call. You can find more complete code examples in our GitHub repo for PHP.

scheduleStarted returns False. When this happens, you can edit the following fields only if the schedule hasn’t started processing.

scheduleStarted returns True once the schedule has started processing. When this happens, the following fields become editable:

Edit payment schedule