[erlang-questions] Erlang for Payment Systems
Mon May 2 07:42:24 CEST 2016
something else you might also want to look into is pcidss and padss
you will be required to comply with these requirements if you intend to
communicate with visa,mastercard and other international payment schemes .
On Sat, Apr 30, 2016 at 6:32 PM, Drew Varner <drew.varner@REDACTED> wrote:
> Joe's #2 goal of correctness and Garrett's use of success typing (Dialyzer
> and type specs) naturally point to property-based testing. Erlang
> QuickCheck (EQC) and other property-based testing frameworks provide
> additional confidence in the code.
> Specifically, generators and shrinking strategies work hand-in-hand with
> Erlang type specs. Basic property-based testing provides a more thoughtful
> way to test code with solid coverage and the ability to try many edge cases
> that a developer may have missed in traditional unit tests. Advanced
> property-based testing with stateful models offers the opportunity to
> uncover elusive concurrency errors that typically show up in obscure bug
> reports. If I were playing with money in an Erlang program, I'd leverage
> these tools.
> > On Apr 30, 2016, at 11:52 AM, Garrett Smith <g@REDACTED> wrote:
> > Decoding data received on the network does not sound like string
> > manipulation - but data decoding. This is one of Erlang's strengths.
> > Once decoded, transforming data and generating string like output
> > (e.g. encoding JSON or XML) can be both very fast and memory efficient
> > - it depends on what you're doing as programmer.
> > There's nothing about Erlang that's particularly weak in these areas -
> > certainly not to ward you off without specifics.
> > I'd say that Erlang's glaring weakness wrt other language options is
> > lack of static typing. However, this comes with the benefit of hugely
> > simplifying distribution. That's a deliberate trade off that's been
> > made in this language. There are ways to mitigate the language's lack
> > of static typing (e.g. see TypEr and Dialyzer).
> > Also consider that there are classes of bugs that cannot be detected
> > by static type checks. And even if you code is bug free (good luck)
> > your code has nothing to say about hardware failure. You need a system
> > that reaches outside your program, which means distribution of some
> > sort.
> > What you're describing is a critical, long running, unattended system.
> > Those are really hard to build and you should put a premium on tools
> > and languages that help you build them successfully (i.e. they
> > actually do what you want at acceptable service levels) at low cost.
> > You'll be hard pressed to find a better language environment along
> > these lines than Erlang.
> >> On Fri, Apr 29, 2016 at 3:09 PM, Hassan Sowwan <h_sowwan@REDACTED>
> >> Hello,
> >> I am trying to implement payment messaging middleware and would like to
> >> explore the option of using Erlang/OTP.
> >> The application will be used in banking industry to interface with EFT
> >> payment switch/networks and core banking system to process card
> >> transactions.
> >> It will be responsible to perform following tasks:
> >> Communicate with external interfaces using ISO 8583 messaging format (
> >> TCP/IP)
> >> Receive huge amount of data over the socket ( HEX, BINARY, EBCIDIC),
> >> represents financial transactions.
> >> Parse/decode the received data.
> >> Perform some checking in database for validation
> >> Interface with host security module to validate customer PIN and other
> >> security checks.
> >> Sends the request to core banking system via XML or web services call
> >> Respond back to external interfaces by formulating the response message
> >> ISO 8583 format
> >> Obviously, such applications have to be concurrent and fast enough to
> >> process transactions within few seconds.
> >> Now my question here, is Erlang a good choice for implementing this
> type of
> >> applications ?
> >> Can Erlang handle string processing efficiently without impacting the
> >> performance?
> >> As stated before, there will be a lot of string manipulation to decode
> >> received over the network, so I am not sure whether erlang fits
> perfectly or
> >> not.
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions