Reccuring Payments & Muhlafim Programmer’s Guide

Index

Recurring Payments – Developer Guide

For customers performing monthly recurring payments, there is a recommended billing method by credit card companies that aims to prevent rejections and significantly reduce transaction processing time. It is important to emphasize that the billing methods suggested in this document are recommendations and are not mandatory.

System Requirements:

  • Supplier and Recurring Payments Terminal The business must open a recurring payments supplier account with the credit card company and a recurring payments terminal with Pelecard to start processing monthly charges through the terminal without receiving rejections from credit card companies.
  • Card Replacement Service (explain in detail later) After each transaction transmission, the credit card companies send updates to Pelecard regarding replaced cards, recurring payment cancellations by customers, and problematic cards. Pelecard receives this information and updates the business with the replacement card file. If a replacement card exists, it is automatically updated in the*token of the customer’s card.*Token – A 10 digit encrypted representation of the credit card, containing the card number and expiration date.
  • Tokenization Businesses can generate a token for each credit card. Each card can have only one token (per terminal).PCI regulations forbit storing full credit card details, so businesses store tokens instead. This allows them to perform monthly billing without storing credit card numbers.If a token is created under the regular terminal, it can also be charged through the recurring payments terminal and vice versa.The business must convert all credit cards into tokens for recurring monthly charges.
  • J5 Authorization- Initialization Transaction J5 is an action that captures credit card authorization. When charging a customer through recurring payments, the credit card must first be validated with the issuing bank.Therefore, for each credit card, a J5 authorization transaction of 0.01 shekel must be performed.If approval is received from the credit card company, recurring payment charges can proceed.*If the terminal is configured in Pelecard as a recurring payment pelecard, the process of capturing the credit limit will be carried out automatically upon the first charge.

Another Working Method:

Using Two Terminals (Regular + Recurring Payments Terminal)

In this method, the business first processes the initial transaction (debit transaction) or creates the token using the regular terminal.
Then, the J5 action and the monthly charge are performed through the recurring payments terminal.

Initial Charge on Regular Terminal, Monthly Charge on Recurring Payments Terminal

When a new customer joins the business, the first charge is typically made using the regular terminal. The business should generate a token during this initial charge and store it for future monthly billing.

Before the first recurring payment charge, a J5 transaction of 1 shekel must be performed for each token on the recurring payments terminal. The credit card company will return an authorization number.

For the monthly billing process, the charge must be submitted with the authorization number. This prevents the transaction from being reviewed by the credit card company at the time of processing and reduces the number of declined transactions

Creating a Token on a Regular Terminal and Charging Monthly on a Recurring Payments Terminal

if the business only wants to generate a token for a new customer without making an initial charge on the regular terminal:

  • A J5 transaction (authorization capture) for 1 shekel should be performed on the recurring payments terminal.
  • If approval is received from the credit card company and an authorization number is returned, the customer can be charged through the recurring payments terminal.

For the monthly billing process, the charge must be submitted with the authorization number received, preventing transaction reviews by the credit card company at the time of processing and reducing declines.

Frequently Asked Questions:

Q: What happens if the customer changes their card between the initial charge and the recurring payment?
A: Pelecard will receive this information from the credit card company and replace the card in the token, ensuring the recurring payment is processed with the new card.

Q: What happens if the customer cancels their card after several recurring payments?
A: If the charge attempt occurs within one month of the previous successful charge, the credit card company will honor the transaction and update the business in the replacement file.

Muhlafim:

General Information

The Replaced Cards Interface is designed for businesses processing recurring payments via credit cards. This interface aims to solve issues businesses encounter when processing recurring payments using credit cards, such as:

  1. Expired credit card.
  2. Card number has been replaced.
  3. Card was declined – cannot be charged.
  4. Card status changed (from valid to invalid).
  5. Recurring payment was canceled by the customer.
  6. Valid cards that were previously reported as invalid.
  7. Reinstatement of a canceled recurring payment.
  8. Card is blocked.
  9. Other issues.

The Replaced Cards Interface automatically updates expired or replaced credit cards, preventing transaction rejections and ensuring seamless recurring payments.

Statuses Returned by Credit Card Companies:

Isracard:

  1. Charge Processed – The customer was charged, and the business was credited, but there is an issue with the card that requires replacement. If no replacement card is available, the customer should be contacted to ensure continued collection. Additional notes may indicate whether the card will be processed next month or not.
  2. Declined – Not Charged – Transactions sent to Isracard where the card has been invalid for over a month, has not been replaced, and was not resolved in the previous month.
  3. Status Changed (Valid to Invalid) – Information about invalid cards that were charged in the last six months from the same supplier, including details on a replacement card and its validity if available. This data does not refer to specific transactions but helps businesses maintain and update their database of valid cards.
  4. Recurring Payment Canceled by Customer – Information about transactions where the cardholder requested to stop recurring charges from the same supplier (including cases related to the Credit Card Law update effective December 2008).
  5. Previously Reported Invalid Cards Now Valid – Information on cards that were previously invalid or were requested to be removed from recurring payments but have now been reactivated and can be used again.

Visa:

  1. Security – Recurring payment cancellation.
  2. Customer Dispute – Recurring payment cancellation.
  3. Customer Cancellation – Recurring payment cancellation.
  4. Card Replaced.
  5. Blocked/Other.
  6. Reinstatement – Reinstatement of a canceled recurring payment.

Leumi Card:

  1. Card Canceled – Recurring payment stopped, etc.
  2. Card Replaced.

REST API - Muhlafim

A function to retrieve all records of replaced cards based on a terminal number within a specific date range.The operation is available at: https://gateway20.pelecard.biz/services/GetTerminalMuhlafim

The following table:

Parameter Description Value
קלט לדוגמא: Sample Input JSON

{
  "terminalNumber": "#######",
  "user": "UserName",
  "password": "XXXXXXXX",
  "StartDate": "02/03/2014 00:00",
  "EndDate": "03/03/2014 00:00"
}
פלט לדוגמא: Sample Output JSON

{
  "StatusCode": "000",
  "ErrorMessage": "operation success",
  "ResultData": [
    {
      "SupplierNumber": "######",
      "CreationDate": " 1/21/2015 5:28:13 PM 8",
      "source": "6",
      "FileName": "M1118383_###### horkeva20340713120449.txt",
      "ActionDescription": "כרטיס הוחלף",
      "Token": "3582575127",
      "CardNumber": "45******4580",
      "NewCardNumber": "45******4580",
      "NewExpiration Date": "1215"
    },
    {},
    {}
  ]
}

REST API - Debit Method Example

DebitRegularType – Most common Method for charging

The most standard and common method for making requests for charging a customer via API.

It is used with the Token + Authorization Number received in previous stages, to send the J4 (Debit) request.

DebitRegularType Request:

				
					{
  "terminalNumber": "XXXXXXXX",
  "user": "XXXXXXXX",
  "password": "XXXXXXXX",
  "shopNumber": "001",
  "creditCard": "",
  "creditCardDateMmYy": "",
  "token": "",
  "total": "100",
  "currency": "1",
  "cvv2": "",
  "id": "",
  "authorizationNumber": "",
  "paramX": "test"
}
				
			

Example Response:

				
					{
    "StatusCode": "000",
    "ErrorMessage": "operation success",
    "ResultData": {
        "PelecardTransactionId": "2614331081",
        "VoucherId": "04-001-089",
        "ShvaResult": "000",
        "ShvaResultEmv": "000",
        "ShvaResultEmvMessage": "תקין",
        "ShvaFileNumber": "4",
        "StationNumber": "1",
        "Reciept": "89",
        "JParam": "4",
        "CreditCardNumber": "455743******3803",
        "CreditCardExpDate": "0927",
        "CreditCardCompanyClearer": "6",
        "CreditCardCompanyIssuer": "1",
        "CreditCardStarsDiscountTotal": "0",
        "CreditType": "1",
        "CreditCardAbroadCard": "0",
        "DebitType": "1",
        "DebitCode": "50",
        "DebitTotal": "100",
        "DebitApproveNumber": "0483694",
        "DebitCurrency": "1",
        "TotalPayments": "1",
        "FirstPaymentTotal": "0",
        "FixedPaymentTotal": "0",
        "AdditionalDetailsParamX": "test",
        "shvaOutput": "0000000455743******380326000409270000000100        0000000010110150001048369400000000000000000004001089    —‰‘€Œ— „†‰…0               test",
        "CardHebName": "ויזה קלאסיק",
        "CreditCardBrand": "2",
        "ApprovedBy": "1",
        "CallReason": "0",
        "Token": "",
        "Tz": "",
        "Uid": "25101213325908825774197",
        "eci": "",
        "xid": "",
        "cavv": "",
        "Terminal": "0882577012",
        "TerminalName": "פלאקארדTEST EMV",
        "AppVersion": "ABS001629l",
        "compRetailerNum": "0300012",
        "dateTime": "1012133300",
        "RRN": "528513483694",
        "Atc": "",
        "TSI": "",
        "ARC": "",
        "TVR": "",
        "AID": ""
    }
}
				
			

Pelebilling - Recurring Payments Interface for Managing Customers

Pelebilling is an interface which can create and manage Recurring Payments. You have 2 options, while using Pelebilling: Requests via API or manual configuration on the interface.

For more information, please refer here.