Heartland’s recurring product, PayPlan, allows you to easily setup reccuring payments on a tokenized credit card.
Create a Recurring Customer
Create a Customer
Create a Payment Method for a Customer
Follow the example below to create a new Payment Method for a customer.The object payPlanService was defined in the customer creation example code above.
Create a Payment Method
Create a Recurring Plan for a Payment Method
Use the following example to create a new subscription plan for a given Payment Method.
The objects payPlanService and paymentMethod were defined in earlier example code.
Create a Schedule
Failed Scheduled Transactions
A schedule with a Failed status is an indication that the merchant must reach out to the customer to obtain new payment information. PayPlan has an email notification that a merchant can opt in to receive a list of all schedules that failed during the nightly processing.
If a card exceeds retries with non-fatal decline codes, then the schedule status changes to Failed but the payment status remains Active. This email notification is based on emailReceipt and emailAdvanceNotice.
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. Eventually these will decline and/or trigger a fatal error. -below-
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 aproximately 24 hours after.
If there is a communication failure, the schedule will fall into an error queue and no updates will be made. Any schedule in the error queue is manually reviewed the next business day. This is exceptionally rare and we do not typically provide any information to a merchant when an instance occurs.
Other fatal errors
A payment status can be set to something other than Active/Inactive only by the “fatal” response codes from an issuer during schedule processing; a one-time transaction does not change a payment method status.
For example, if we process a schedule with a card and the issuer returns lost/stolen, then the schedule status changes to failed and the payment status changes to Lost/Stolen.
If a card exceeds retries with non-fatal decline codes, then the schedule status changes to Failed but the payment status remains Active.
Once the payment method is updated an edit can be performed to restart the schedule.
You can find customers associated using this method call.
Find Payment Methods
You can find payment methods associated using this method call.
Find Payment Methods
You can find schedules associated using this method call.
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. More complete code examples can be found in the SDK
scheduleStarted = False
The following fields may only be edited when the schedule has not started processing