Software Company in Alpharetta, GA: One Card Traced Through the Systems That Touch It

Updated November 2026 · Written and maintained by the Progression Agency strategy team

A card is tapped at 7:02 in the morning and within a second it has touched a reader, a gateway, a processor and a ledger. A software company in Alpharetta building for payments has to know, at each of those stops, whether its code is in scope. Along Georgia 400 and across metro Atlanta that question decides what a feature really costs. This page follows one card stop by stop and draws the line where card data enters and where it stays out. It is for product, engineering and compliance leads at payment firms. Progression is a New York team working with Alpharetta firms remotely, with on-site sessions on request.

7:02 a.m., one tap

Follow a single payment for two seconds and a day. The timeline names the stops this page uses, and each one gets its own section.

At each dot the question is the same: does this system see the card number, or only a token that stands in for it? The answer decides how much of your code, your servers and your staff sit inside the review your acquirer or assessor asks for.

What a software company in Alpharetta draws first

The first drawing is the scope line. The PCI Security Standards Council states that its standard applies to entities that store, process or transmit cardholder data or sensitive authentication data, or could impact the security of the cardholder data environment. It names merchants, processors, acquirers, issuers and service providers, and it currently publishes version 4.x of the PCI DSS. Everything in the build is easier when the line is drawn before a screen is designed.

Alpharetta sits along Georgia 400 in north Fulton County, and a lot of payment work in the Atlanta area is done by teams that sit in different buildings from their processors. That is why the drawing matters: the line crosses organizations as often as it crosses code. Your assessor decides scope for your system. This page is a way to prepare the conversation.

• Draw each system that touches a card, in order of the payment.
• Keep the drawing on one page so the whole team can follow it in a meeting.
• Mark the ones that see a number and the ones that see a token.
• Write down who operates each one.
• Bring the drawing to your assessor before you build.
• Redraw it whenever a feature adds a stop.

Stop 1: the reader or the checkout page

On a counter, the reader is a certified device from your provider. On a web page, the question is who owns the field where the number is typed.

A form you build and host puts your page and everything loaded on it near the number. A field served from the provider keeps the number in the provider’s frame, so your page only receives a token afterward. The hosted option reduces what your code touches. It does not decide your scope for you; ask your assessor.

What goes into the checkout build?

A hosted payment field, a page that loads as few third party scripts as possible, and a clear message when the provider rejects a card. The less your page does around the field, the less there is to review.

Stop 2: the gateway

The gateway turns a typed or tapped card into a token and a result. What comes back to your system is what your database may keep.

• Store the token the gateway returns, not the number.
• Store the last four digits and the card brand only if the product needs them.
• Keep the security code out of every table, queue and cache.
• Record the gateway’s own transaction identifier so refunds and disputes can find the payment.
• Ask your assessor before you store anything else from the card.

Retries are the quiet trap at this stop. A job that resends a failed payment needs the token, not a copy of the request body, so the retry queue does not become a second place card data lives.

Stop 3: the processor

The processor routes the payment to the issuing bank. Most software companies never touch this stop directly, but some do, and the contract language decides which side of the line they sit on.

If your product handles card data on behalf of merchants, you may be a service provider in the PCI sense, and the merchants will ask you for documentation. Whether that applies is a matter for your assessor and your contracts, not for a feature list.

Who writes the assessor’s paperwork?

Your organization owns the assessment. A written scope can say which diagrams, data flow notes and system descriptions we produce from the build, and which documents only your assessor or your own staff can write.

Stop 4: the ledger

The ledger is your own record of what happened: amounts, times, token references, statuses. It is where most of a payment product’s logic lives and it should never need a card number.

The cards list what a log test looks for. A test that scans logs, error reports and exports for number-like strings on every release catches the leaks that no design document predicts.

Stop 5: the settlement file and the support desk

The last stop is people and files. A settlement file reaches finance, and a support screen reaches staff who answer questions about a payment.

Staff screens are where good designs most often fail. A screen that shows more than its job needs is a decision someone made in a hurry, and the fix is a short list of who sees what.

• Write the role list before the screens are drawn.
• Review the list each quarter and whenever someone changes jobs.
• Log every time a payment record is opened.
• Turn off exports that nobody uses.

Which stop do we build first?

Teams often start at stop one because it is visible. The cheaper order is usually the reverse: settle the ledger and the logs first, because they decide what every other stop is allowed to send.

• Build the ledger and the log test before the checkout polish.
• Wire the gateway with a sandbox and test card numbers from the provider.
• Add the support screens last, with masking turned on from day one.
• Review the drawing at each handoff between stops.
• Name one person who signs off each change to the drawing.
• Store the drawing next to the code it describes.
• Date every version.
• Keep a changelog of what each release added to the drawing.

Who owns which part of the work?

A payment build involves four parties, and clear lines between them save more time than any tool. The table puts each one beside what it owns.

Can an agency be the assessor too?

No. Progression is not an assessor, and an independent assessor should be someone who did not write the code. We build to the drawing and hand over the documents the scope names.

What happens when the drawing and the product disagree?

The product changes or the drawing does. Either way the change is written down before the next release.

What each stop costs to build

A software company in Alpharetta, GA prices payment work by the number of stops in play and how much each one asks for, not by the logo on the product. Hosted fields at stop one cost less than a form you own. A ledger and a support screen cost the same in either case.

What do published bands say about payment software?

These bands run from the typical low to the published high for each kind of work.

Hosting, licenses and security testing are on top of these bands. Progression quotes after a written scope.

What costs sit outside the code?

Assessor fees, penetration tests and scanning services are separate lines from the build. They belong in the plan from the start, and they depend on your size, your provider and how many stops your own systems sit on.

Moving money is a different question

Passing a payment through a gateway is one thing. Holding or transmitting funds for other people is another. Georgia licenses money transmitters through the Department of Banking and Finance, and other states have their own offices.

If your product moves value between people, ask counsel before the design freezes, because the answer changes what the product is allowed to do. For the build side of financial products, see our fintech software development page.

For apps on the consumer side, see our app development company in Atlanta page, and for search work aimed at Georgia buyers, our SEO company in Georgia page.

Related services and guides

Pages that sit beside this one:

• Software development company
• Fintech software development
• Software consulting services
• App development company in Atlanta
• SEO company in Georgia

Frequently asked questions