Card Storage and Recurring Payment Flow

A. Our dealers can store their customers' cards on Moka and can shoot from these cards in 3D or Non-3D whenever they want.

B. Apart from that, Moka can also take over the regular shooting. Regular-Recurring Shooting (Recurring Payment) is made by Moka only in Non-3D.


A. To Store Card and pay from the hidden card, respectively :

  • customer is added first ( with our AddCustomer service)
  • A card is added to this customer ( with our AddCard service). Moka returns "Token" as a result of the added card and the dealer saves this Token himself.
  • It can also add the customer and the card at the same time with a single service. ( with our AddCustomerWithCard service)
  • The Dealer can send payments via Token (without sending card information) at any time using our regular payment services ( DoDirectPayment or DoDirectPaymentThreeD ).

B. For recurring payments :

  • As above, Customer and Card are added. ( with our AddCustomer and AddCard or AddCustomerWithCard services)
  • The products that the dealer will sell are added. ( with our AddProduct service)
  • Time Schedules are added to show when payment withdrawals will be made. - daily, weekly, monthly etc.- ( with our AddSchedule service).
  • Sales are made to the customer. ( With our AddSale service) - Thus, information about which customer (Customer), which product (Product) was sold, how often (schedule) payment withdrawals will be made from which card (Card) is given.
  • When the payment dates of the sales made come, Moka system will automatically create a payment withdrawal step (PaymentPlan) and will make the withdrawal from the card defined in the sale.
  • Attempts will be made 2 times a day (at 12 noon and 6 pm), and the number of days (HowManyTrial) that will be attempted will be given when creating a sale with our AddSale service. Details of these withdrawals will also be kept as PaymentPlanHistory. Therefore, for a payment step, more than one History record may occur. eg: the first attempt is unsuccessful, and when the next attempt is successful, 2 History records are created.
  • If the dealer wishes, he can also add payment plans manually. Or Moka may say that I will add all plans, even if they don't automatically add payment plans. ( with our AddPaymentPlan service)
  • The dealer can retrieve the list of payment steps of a single sale (GetPaymentPlanList), the report of payment steps of all sales ( GetPaymentPlanReport ) or the list of histories of payment steps ( GetPaymentPlanHistoryList ) at any time through our services.
  • As another option, each time a payment withdrawal attempt is made (at 12 and 18 o'clock), the withdrawal- related fields can be POSTed to the URL ( RecurringReturnURL ) that the dealer has previously notified Moka . The following fields are included in the POST to the URL:

HashInfo :  DealerCode + Username + Password + PostToken fields are combined and hashed with SHA256 and compared with the HashInfo field. If it's the same, this POST came from Moka.

PostToken :  It is the GUID value produced by Moka for each withdrawal attempt. It is used when obtaining hash. (with the above formula)

DealerCustomerId :  It is the ID that the customer who is withdrawing is defined in the Moka system..

CustomerCode :  It is the code that the customer, which is withdrawn, is defined in the Dealer's own system.

DealerSaleId :  It is the ID that the withdrawn sale is defined in the Moka system.

SaleCode :  It is the code in which the captured sale is defined in the Dealer's own system

DealerPaymentPlanId :  It is the payment step ID for the sale. payment steps occur according to the time schedule given in the sale. (daily, weekly or monthly). In addition, manual payment steps can be added if desired. More than one shot attempt can be made for this payment step. If the first shot attempt is unsuccessful, the second attempt is made. For each card given at the time of sale (maximum 3 cards can be given), a trial is made and POST is fired for each trial.

DealerPaymentPlanHistoryId :  It is the history ID of each withdrawal attempt made based on the payment step. For a payment step (DealerPaymentPlanId), more than one (DealerPaymentPlanHistoryId) can occur.

DealerPaymentId :  It is the payment ID generated as a result of the withdrawal attempt. You can see the payment details with this ID from the Moka dealer panel.

Amount :  It is the amount withdrawn from the card.

HistoryStatus :  The result of the capture attempt. (0 : Failed, 1 : Successful)



CREATE AUTOMATIC PAYMENT STEP AND ADD MANUAL PAYMENT STEP

If the dealer says create an automatic plan (PlanType : 1) while making the sale ( AddSale ), Moka system automatically creates a payment step (DealerPaymentPlan) when a payment day comes for that sale. For example, a sale can be made from customer X to withdraw 200 TL on the 5th of each month. In this case, it is sufficient to arrange the time schedule (DealerSchedule) to be on the 5th of each month. (Of course, the customer ( AddCustomer ) and the product ( AddProduct ) need to be introduced beforehand).

As soon as the dealer makes the sale and says create an automatic payment plan (PlanType : 1), when the 5th of that month comes, the Moka system automatically records a payment step (DealerPaymentPlan) that a payment will be made for this sale, and 2 times a day. (at 12 and 18 o'clock) it tries to perform this payment step. The histories of this payment step (DealerPaymentPlanHistory) begin to form. Even if he failed on the first try, let's say he succeeded on the second try. In the history, 2 records are created for that payment step.

If it is clear in which interval (daily, weekly or monthly) and what amount of money will be withdrawn, it will be sufficient to mark as Automatic payment plan will occur when adding sales. However, in the meantime, if you want to get another payment depending on the situation, and the amount will be different, then it should be marked as I want to add a payment step manually besides the automatic one (PlanType : 3). In this case, the dealer adds a payment request order (payment step) at the desired date and amount under this sale. When the manually added payment step is due, the payment is withdrawn from the card as per this request. Automatic shots continue as well. In other words, manual payment allows the dealer to add any amount of payment on any date and at any time. (it can be thought of as a kind of flexible interim payment option). Resellers do not have to use manual payment.

In some cases, the dealer may request that the payment step is not created automatically, so that I can always decide how much withdrawal will be made on which date. For this type of sales, PlanType : 2 is entered. And the Moka system never automatically generates a payment step for this sale. But when the date of the manual payment step comes, the card is charged.