Episode 555: Web Reception, But No Card Information (2)

Sunday, October 1, 2017

Operation: Charging to Registered Card

I did create a mechanism of "Credit card registration"! (See previous post)

The mechanism is, credit card information such as "card number" and "CVC" is committed to Stripe (Payment Service Provider), and only "Stripe Token" (tok_ {24 characters}) as "deposit number", flows to Workflow. That means, it complies with what Japanese government is advocating that "Achievement of non-possession of credit card info by March 2018". (Non-possessing = The primal measure for protecting credit card information)

This will bring down "the risk of credit card info breaching from in-house system" to zero! Customers can make web registration without worry!!

* Stripe Token is a specification that can only be used for one processing (single-use token). In this example automatic conversion from "Stripe Token" to "Stripe CustomerID" (cus_ {14 characters}) is also done simultaneously. (Auto-step "Token to Cus_ID")

Challenge: Eliminate Manual-work in Charging Operation

But wait and look. What I did is just realized only "protection of credit card info".

Mistakes in "Total amount", for example, or in "Charge"... Risks of occurring such error in "charging operations" is not yet zero. Suppose if you had sent a charging statement to "email address of Mr. Brown" with "addressee name of Mr. White"...doesn't it make you shill?
  • Customer's name
  • Customer's email address
  • Token or Customer ID
Data like as above should be automatically entered beforehand. By making so, error rate will be close to zero. The burden on "unreliable boss" who is in charge of checking at the downstream Step will be alleviated a little.

[Credit Card Charging]

[Credit Card Info Reception - Connect to Charge]

Solution: Data Linkage between Business Processes

By linking two Business Processes of "A) Credit Card Info Reception" and "B) Credit Card Charging", it becomes possible to automatically start B Issue which has taken over partial (or the whole) data in A Issue.

* As a concrete flow setting, place [Throwing Message Intermediate Event (HTTP)] near the final process of A, and [Message start Event (HTTP)] at the beginning of B.
* Reference manual: M411 PROCESS CONNECTION' Auto-starting “Billing Process” Triggered by “Shipping Process”

In "Credit Card Charging" introduced here, four data of "Customer's name", "Email address", "Stripe Customer ID", "Last 4 digit" are inherited in advance of start. That is, you do not need to enter information about customers or Stripe at the time of the first human step of "1. Charge amount entry", so you can concentrate on information input such as "Charging amount" and "wording in charging schedule notification email".

Discussion: Second and Subsequent Credit card Charges

In the case of "billing sales charges to regular customers monthly" for example, "credit card charging process" needs to be started every month.

In such a case, (instead of waiting for automatic start from the "Message Start Event") start a Process from manual restart at the human Step of "1r. Charging amount entry", and make charge reusing "Stripe Customer ID" of the last month. In other words, you do not have to ask regular customers to "register credit card information" every time.

Incidentally, regarding when you manually start "1r. Charging amount entry", it is OK to manually copy and paste all the items. But if you use the previous data by [Start a new process with these data] function, you can start a Process in which all data has been copied. In other words, you only have to edit items that differ in value from the previous charge, such as "Amount of money" and "Charging date and time".

* Reference manual: M103 STARTING: Starting with Past Data

[Credit Card Charging:"1r. Charging amount entry" screen]

[Data Items list]


[Free Download]
<Similar Models>
<<Related Articles>>

[Japanese Entry (ε’Œζ–‡θ¨˜δΊ‹)]