One of the ways one can test outbound or egress firewall rules is a tcp connection test.

I recently discover portquiz.net. Port Quiz is an outgoing port tester and gives connection examples for various clients, telnet, powershell, nc (netcat), curl, wget, etc… I’ll use PowerShell in my example below.

Why would you need to use this, a recent example that we had was - is that we had some SIP phone users that had some connection issues - as the first step was to see if tcp/5060 (SIP) was accessible from their soft-phones. Was it blocked by their ISP? or some other issue?

Portquiz to the rescue:

1

PS>Test-NetConnection -InformationLevel detailed -ComputerName portquiz.net -Port 5060

For example, SIP is blocked from this machine and they needed to check with their ISP for further troubleshooting.

Portquiz is a handy internet facing website that listens on all ports and allows for egress network testing.

I decided to try a static blog generator and move away from WordPress and get with the times :)

I’m using Hexo - https://hexo.io and using Netlify as a host. Here is the quick start guide that I followed:

https://www.netlify.com/blog/2015/10/26/a-step-by-step-guide-hexo-on-netlify/

I found my old WordPress XML backup files and migrated those pages using https://github.com/hexojs/hexo-migrator-wordpress. I do have a bit of clean-up for images and markdown formatting to clean up for a few posts, tags and categories - or let the old posts die, or remove a few of the poorer ones.

I found out that my first blog post was 11 years ago, and my most recent about 5 years ago, I do think that Twitter and micro-blogging took away from some of the blog writing I used to do.

From a development effort at work - we are writing docs in asciidoc http://asciidoc.org and using Antora https://docs.antora.org/antora/2.0/. I suspect that was part of the motivation here for a change, and fewer concerns of keeping Word Press and its plugins up to date is a nice bonus.

In the early days, when computer networks and processing power of point-of-sale and payment terminals was limited by then current-technology, the focus was on efficiency. Payment transactions generally only contained a few data elements of data required to process the transaction, and implemented technically in a manner that saved as many bytes as possible. This was important so all of this would work over a dial-up line and only send required data for transaction processing. Much of the payment message formats are tied to this legacy heritage to this date.

In the world of ‘Big Data’ there is a growing trend of providing fatter transactions, and providing more data in these transactions. These transactions consist of more then the final amount of the transaction and payment information, but now with market basket data and line item detail.

What does this involve from a payments system perspective ?

1) Expanding message formats and APIs to include list of skus and UPCs and other meta-data of market basket items.

2) Processing against a catalog to perform various value added services and processing.

3) Parallelism in transaction processing as certain items require processing that would take too long if processed in a serial manner.

4) Development of systems including robust engines and processing logic leveraging Machine Learning techniques to mine and process such data.

This isn’t new in concept as it has been performed locally in retailers for sometime now, as well as in some level-3 purchase/commercial cards. Now there is a trend of more value added services to enhance payment processing such as item based loyalty rewards, when such data is available you have more options and capabilities to enhance the payment transaction.

Soft Decline vs Hard Declines

We were discussing Result Codes (aka. Response Codes) during a call today. We were discussing both “Soft” and “Hard” Declines and the differences of them in the context of reviewing a payment interface and which transactions could be Store-and-Forwarded (‘SAF’).

Result codes are returned in Field or Data Element 39 in an ISO-8583 message.

We use the term “Soft” decline when a subsequent transaction request containing the same pertient information could recieve a different result.

These typically occur from a transient system issue or payment network issue and are temporary in nature.

Examples of some result codes that come to mind:

• “19” Re-Enter Transaction
• “91” Issuer Unavailable or Switch Inoperative
• “96” System Malfunction or System Error

Hard declines contrast from Soft declines in that on a subsequent transation request, the responses are repeatable; you will recieve the same result.

The best team members are those that I call The organized ones. or·gan·ized (ôrg-nzd) - Efficient and methodical A list of observations of some traits and activities : * Usage of folders and mailbox rules to process emails, vs an inbox with 4999 unread emails. * Searching for files on keywords using Spotlight or Windows Search vs navigation of windows in a file manager. * Using Find in Files or $grep -r “something” * or in your favorite text editor * Doesn’t duplicate documents or content all over the place - e.g. lets write this is a word doc, and copy and paste the contents to a comment on issue ticket, and then attach the word doc with the ticket, and then store the word doc in Dropbox. * Usage of 1Password, LastPass or some other password manager and don’t forget passwords. * When you browse a file tree in a directory and sub-directories - there isn’t too much ambiguity and depth. * Searching though chat history to find some that was discussed recently. * Using search (see a theme ?), for e-mails. * Just google it, open a bunch of tabs/links and read, instead of saying they don’t know, or nobody told them. * Tend to use the keyboard a lot more then their mouse, and actively research shortcuts to improve efficiency. * When talking to them getting the feeling that they haven’t confused themselves. … @dbergert

I lead development and IT teams. Many of us work remotely. We leverage group chats for effective team communication. We tend to use Skype as a tool to perform this, but you can use other tools: Campfire, HipChat, IRC, jabber, etc. Also - have a backup plan - when your primarily venue is not available. If you are used to working this way, and have an IM outage, it is like losing the internet. I’m serious. The key to dev chats is that they are asynchronous in nature. This is important. If you don’t answer a chat that means that you are not there, or are engaged in something else. You are not required to respond and state that you are busy or on a call. You simply don’t respond. Messages can be queued for later consumption and review. Most IM programs have a list of unread chats that can be reviewed. You are expected to configure your notifications, actually disable and mute them. I despise being on conference calls where IM beeps and dings occur in the background. I’m not sure how you can concentrate with all of those auditory and visual distractions. We have the following chats: Off-Topic (OT) The OT Chat is the water cooler talk. We broadcast “Lunch Time”, “Good Morning”, “Have a good evening”, cool links from HackerNews or Reddit’s /r/programming and other general things that keep us human and feeling apart of a team. It helps with culture as well. This is an optional chat, and maybe segmented by teams or departments, but very important to have, especially if you work from your basement, and don’t get out to lunch or coffee very much. Project Chats Project Chats tie to a project, lots of discussion occur here. Daily Standing-Meeting/Chats, priority expectations, requirements clarifications, testing / support, and general questions all live here. Each project chat has a distinctive name, and a cool icon to make it fun. Many discussions here are promoted to a YouTrack tickets. And general status updates are shared here as well with the team - These are much better them synchronous phone calls with project status updates. There are also plenty of - is this done yet or what is the ETA on xyz. Certain projects have additional chats with -MGMT, -DEV, -IT-OPS suffixes. Mangers can discuss project related task with dev leads and PM’s, without distracting the rest of the teams, and Dev’s can really geek out on more technical conversations when required. Guidance depends on the team size to split these out or not, IT-OPS cares about deploying and supporting apps based on more concrete release notes, not necessarily who committed what fix for a given ticket. So we try to segregate folks when it makes sense to. Private Chats Private Chats are generally discouraged, especially if the topic makes sense to discuss in a project chat. I discourage them for the following reasons: If they are private, others can’t learn from them or share their experiences or advice. If you are embarrassed or too shy to make a mistake in a group chat, then you are afraid to learn. If you are afraid of verbosity, keep it in the project chat unless other ask you to take the conversation offline. Tips * Use gists, screencasts, and use clickable links or permalinks in chats to ticketing systems, code repos, documents to make navigation easy. * < Ctrl-F > and search is your friend here. Search first, then ask - folks will paste repeated questions that have already been answered. * Promote ideas and conversations to appropriate venues, “Can we make a ticket for that” is often typed to facilate this. * Don’t be afraid to get on a phone call to discuss something, * Things can be missed in chats, if it is important make sure you have a tickler or enter in as a task or issue, vs assuming someone will remember to review history to address something. * Having a second monitor with dev chats on the side is also a good tip, off to the periphery… * Get face to face when you can as well - either physically or virtually - group video chats, and hangouts are fun to do from time to time. … @dbergert

localtunnel is a pretty neat tool. It solves the problem of quickly exposing a web server to the internet without messing with deploying to a “test server” messing with a router/firewall and NATing/PortForwarding. It works like this, assuming you have a webserver listening on port 8080 dbergert$ localtunnel -k ~/.ssh/id_rsa.pub 8080 This localtunnel service is brought to you by Twilio. Port 8080 is now publicly accessible from http://52rq.localtunnel.com ... Now browse to the URL and there is your publicly exposed webserver for that quick show or test. More on localtunnel on its github page: https://github.com/progrium/localtunnel

We use Veeam for VM backups and VM replication in our datacenter. We also run virtualized labs and smaller ad-hoc Vmware ESXi servers for dev teams. So I was very happy to see Veeam offer - Veeam Backup Free Edition My old options for ad-hoc VM image backups where to stop the guest and use Veeam’s FastSCP to an external NAS for backups. This was a pain and only done in frequently. With VeeamZip I can queue some live backup jobs on a running VM and later robocopy them to an external NAS. Similar steps but a lot less painful and time consuming, and a bit easier to setup then ghettoVCB.sh

We recently were talking a lot about reversals this week in the OLS HQ, especially time-out reversals. Andy even mentioned his ever so famous “Refunds are not Reversals” So I was happy we were talking about reversals and not refunds ;)

Situation: What happens if you send a financial transaction to a payment system and we don’t get a response back? You are obligated to reverse it and keep on trying to reverse it (reversals are normally Store-and-Forwared (SAF) until you get a response back that the reversal was accepted.

You would be surprised how many implementations of payment software do not implement this important step, a disaster of not performing this is duplicate charges to cardholders during system or communication issues. This needs be be implemented in each path of a transaction. Terminal to Gateway, Gateway to Switch, Switch to EndPoint. for example. Many applications get-by, by ignoring reversals on Credit product types where cardholder have large open-to-buys and on Authorization Only Transaction Types. Reversal for Debit and and other financial transaction sets are a must.

On our Switch we handle Reversals with Idempotence. Wikipedia defines this as:

Idempotence ( /ˌaɪdɨmˈpoʊtəns/ eye-dəm-poh-təns) is the property of certain operations in mathematics and computer science, that they can be applied multiple times without changing the result beyond the initial application. The concept of idempotence arises in a number of places in abstract algebra (in particular, in the theory of projectors and closure operators) and functional programming (in which it is connected to the property of referential transparency).

Another website describes the problem as:

Problem: Network and server hardware failure can lead to lost messages, resulting in cases where a service consumer receives no response to its request. Attempts to reissue the request message can lead to unpredictable behavior within the service and the service consumer logic.

Solution : Design service capabilities capable of safely supporting repeated message exchanges.

Our implementation of reversals can handle multiple attempts of a reversal, we only process one but will accept any number of them. This is very important, Reversals are not “approved” or “declined” as the endpoint may or may not need to unwind anything. You as a caller don’t know whether the timeout was actually not processed at all, or if it was processed but you just didn’t get the response back.

We have the following ISO8583 v2003 based result codes in OLS.Switch for this so we can note the difference.

4000 Advice Accepted

4999 Advice Accepted - no Action Taken

That also means your logic is very simple - “send this reversal repeatedly on an interval until I get a response”

From the Mail Bag:

“I have a couple of questions you can help answer. Is it normal for a manufacturer to program POS terminals themselves? I have received contradicting answers to this question. Also, from the terminal, the [encrypted] cardholder information is sent to a processor. Do processors possess unique internet addresses that they give to the merchant to where the terminal can send this information?”

Great questions - let me take a stab at answering them:

“Is it normal for a manufacturer to program POS terminals themselves?”

It really depends - There are two models in play here, a) you can pay a terminal manufacture to development a terminal application, b) terminal manufactures also generally will sell SDKs, Software Development Kits, as well as required or optional training courses for independent developers to write payment applications for. From my personal experience, we have worked with both terminal manufactures as well as independent developers, as well as wrote very few in house.

“ Also, from the terminal, the [encrypted] cardholder information is sent to a processor. “

This is true in certain situations and depending on the application, terminal, and communication methods. Most dial terminals send cardholder information in the clear across a private dial line. Many IP/SSL terminals will just use SSL encryption as a transport mechanism for encryption/security. More recent generation of terminals and those that implement End-to-End Encryption (E2EE) or Point-to-Point Encryption will use both a data level and transport level encryption/security. Our message specifications and when we can enforce it, we always try to use tokenization, or surrogate numbers for subsequent transactions (Refunds, Captures, Voids, Reversals, - do not require the full PAN to be passed in many of our systems that we develop)

“Do processors possess unique internet addresses that they give to the merchant to where the terminal can send this information?””

Payment Processors and/or payment gateways will provide either dial 800 numbers for dial payment terminals or an IP address or https/SSL based URL for IP/SSL based terminals to send transaction data. OLS has integrates to various dial concentrator devices/networks - Hypercom NAC, TNS, HB.Net, now Phoenix Managed Networks, for Dial delivery. We have developed our own secure SSL Transaction Servers with various interface options for our customers, IP SSL Sockets, HTTPS Post, RESTful as well as SOAP based web services.