Standing up a card program involves a lot of players, from a card network to an issuer to a ledger that can authorize payments and track how much money has been borrowed. That's where LoanPro comes in. We've built two key components: a servicing core to manage accounts, and a card system that partners with issuers and networks to enable account holders to draw funds through a card transaction.

Authorization path

When a borrower swipes a card at a convenience store, there's a chain of interconnected companies and technologies. When a borrower makes a swipe, it typically follows this authorization path:

The merchant sends it to their acquiring bank, who passes it to the card network (a company like Visa or American Express). They route it to an issuing processor, which queries a ledger to make sure the borrower is allowed to make that swipe. (In our system, LoanPro acts as the ledger.) Then, the information flows back in the opposite direction, with approval going from the ledger to the issuer, then to the networks, the acquiring bank, and finally the merchant. Once the merchant receives confirmation that the swipe is approved, they can deliver their good or service and send the customer on their way. This all happens in milliseconds.

This is how LoanPro's card system works.

Cards and lines of credit

LoanPro provides two key components for your credit card lending operation:

• A system to create cards through an issuing processor and capture card transaction information
• A servicing core to calculate interest, service accounts, and collect payments.

When you create a borrower and line of credit account in LMS, our servicing core, you'll also be able to issue the borrower a card which they can use to access their available balance. You can enter that borrower's card-associated information in the more user-friendly LMS, and then it'll be saved in our PCI-compliant software, Secure Payments.

From Secure Payments, that card is connected to the issuer and card networks on one side and LMS on the other. When a borrower makes a swipe, the information goes through the authorization path to the Secure Payments authorization service. Since Secure Payments stores all the card's information (like an available balance and swipe limits), it can authorize the transaction without querying LMS. When Secure Payments approves the transaction, it sends that information back through the authorization path and to LMS. LMS then routes the transaction into the correct bucket and updates the account's available balance, including an update to the Secure Payments authorization service so its balance information will be accurate.

Structure and hierarchy

In Secure Payments, there's a basic structure to the card system. Each level of this hierarchy is a one-to-many relationship; a single card can have hundreds of swipes, but a swipe can't be shared between two cards.

1. Secure Payments account - Each lender using LoanPro gets an account with Secure Payments, our PCI-compliant system for storing card and payment profile data.
2. Issuing processors - Within your Secure Payments account, you can integrate with multiple issuers by connecting your issuing partners to the Secure Payments API. 
3. Card programs - A card program is the template used to create cards. This is similar to the line of credit programs in LMS, but not the same. Both are templates, but they create different entities. A line of credit program creates accounts, and controls things like buckets, interest calculation, and servicing defaults. A card program creates cards, and controls the issuer, network, and what kind of swipes are blocked. An issuer can support multiple card programs, but each card program is limited to using a single issuer.
4. Cards - You can use card programs to create cards for borrowers. It inherits all of its settings from the card program, except for the borrower-specific info like their name and billing address. Most of those settings can be edited on individual cards, but the card is locked in to the issuer and network that the program uses. Cards can be physical pieces of plastic, electronic cards (like the card you might have saved in your smartphone), or both.
5. Swipes - These are transactions where a borrower uses the card to pay a merchant. Swipes can be a single transaction that authorizes funds and makes the payment, or they can be broken down into an authorization message that approves the transaction and a clearing message that actually moves money. (That two-step swipe is common for transactions where it's not immediately clear what the exact cost will be, like filling up a tank of gas. The authorization message makes sure the card has enough money, and the clearing message charges them for a specific amount.)
6. Swipe events - When a swipe gets cleared, voided, returned, or otherwise modified, that change comes into Secure Payments as a swipe event, saved to a specific swipe. 

BYOIP

When it comes to which issuer processor to use, the choice is entirely yours:  Choose between one of our natively integrated issuers or bringing your own. Our Bring-Your-Own-Issuer-Processor (BYOIP) infrastructure means that LoanPro is completely agnostic towards issuers, leaving you free to work with the issuer of your choice.

Once you've selected an issuer (or several issuers), you can use the Secure Payments API to connect them to our system. Secure Payments is already connected to LMS, so the issuer doesn't actually need to touch LMS directly.

API and webhooks

Secure Payment's API and webhooks let lenders connect any issuer and card network into our card system and servicing core.

Webhooks let Secure Payments communicate with LMS and other software when certain events happen, like card creation or swipes.

The Secure Payments API is how you can get your information into Secure Payments. There's plenty of calls you can use (like those to add new card programs or edit a card's transaction limits), but these are especially important: 

• Creating a new card - While some lenders might be content to use our UI to add cards, we anticipate most lenders will want to use their own website or customer portal to handle card applications. This call will let your application send that borrower's information into Secure Payments.
• Log a swipe - When a swipe comes in from the authorization path, this is the call you'll use to send it into Secure Payments. This is essential for authorizing and recording new swipe transactions.
• Swipe events - These endpoints will let you modify a swipe. Not only is this used to void or refund a transaction, but it's also an essential part of dual message system (DMS) transactions, where a first message puts a hold on funds, and then a second clears a specific dollar amount. 

Issuers

Issuers are vital to the connection between LoanPro and the card networks that your customers use every time they make a swipe. If you don't have a connection with an issuer, you'll be unable to extend credit through a card that's linked to the accounts saved in LoanPro. But once that connection is established (which you can do with whatever issuer of your choosing), you'll be able to issue cards from within LoanPro, and your customers' activity will flow seamlessly through the authorization path, ending with a complete record of the transaction saved in LMS.

It's important to understand the role issuers play within the context of the broader card system. They're a crucial link in the chain of financial systems that connect customers to the financing programs you've launched. 

Issuer role in authorization

Following the same authorization path, when a card is swiped information is quickly transferred. From the merchant, to the acquiring bank, through the card networks to the issuing processor, who issued the card in the first place.

The issuing processor then connects to the ledger managing the account—in this case, LoanPro. If the card allows the transaction (meaning it has enough available credit and there are no other restrictions), then that authorization flows back through the path until it reaches the merchant, who can now finish their transaction with the customer.

And at the same time that the issuing processor gets approval information from LoanPro, they also send in transaction information that helps route the swipe to the appropriate bucket. Information about the amount of the purchase, the time and place when it was made, the merchant category code (MCC) for the store, and other details will all work through the transaction routing in LMS to sort the swipe into the right bucket based on your business logic and policies.

Card programs

Just like how line of credit accounts are created from program templates, the cards are created from programs of their own. Card programs let you preset the majority of information on a card, which streamlines the process of creating and issuing them to borrowers.

Card programs are created and saved in Secure Payments, LoanPro's PCI-compliant sister software. Whenever you create a new card, you'll just choose a program, and all of its settings will be copied over. You'll then be able to customize most of those settings to personalize an account for a specific borrower.

Using programs as templates means that you can design complex, nuanced cards and then launch them at scale with minimal setup on individual accounts. Settings like swipe expiration, swipe restrictions, and spending limits can be set at the program level and then fine-tuned for individual cards.

A few settings, however, are locked in at the program level:

• Issuing processor – When you create a card program, you'll select an issuing processor. This is one of the few settings that can't be edited on individual cards; whatever issuer you choose, all the cards made from this program are permanently linked to it. (This makes sense if you think about it—only one company issues an individual card.)
• Swipe enrichment – Swipes processed with created credit cards will include enriched merchant data, which includes the merchant logo, location, URL, phone number, address, merchant category and more.
• BIN – These bank identification numbers (BIN) are part of the sixteen digits that make up a credit or debit card, and they communicate information about the card and issuer to merchants. Setting them at the program level ensures all the cards created from this template fit within the right range.