Bill Payments using RPPS
TabaPay offers bill payments via MasterCard Remote Payment and Presentment Service (RPPS).
The MasterCard Remote Payment and Presentment Service (RPPS), governed by MasterCard International, is a fully electronic solution for bill payment processing that provides electronic routing, posting, and same day settlement of financial transactions.
Participants
Participant | Detail |
---|---|
Originator/Originator Bank | The Originator originates payment transactions to RPPS using TabaPay as the service
provider to originate payments files to RPPS. The Originator’s Bank is a financial institution used by any Originator. It is the institution from which the MasterCard Settlement Bank obtains funds via a Fedwire to credit Receivers for payment files sent through the RPPS network. If an Originator is unable to fund payments sent through the RPPS network, the Originator’s Bank would be responsible for guaranteeing the funds for the Originator. |
Biller | The Biller is a company to which a MasterCard RPPS payment transaction is sent |
Biller’s Bank | A Biller’s Bank is a financial institution that receives payments on behalf of a Biller from an Originator via the RPPS network. |
TabaPay | TabaPay is the Originator’s Service Provider connecting to MasterCard RPPS for bill payments originated to the Biller via RPPS. |
MasterCard RPPS | MasterCard RPPS maintains all connections between Originators and Receivers to transmit data and funds. It allows all parties involved to have one connection to reach multiple Originators and Billers, and maintains all connections, performs extensive edit checks on all files and payment transactions, batches and sends all files, and initiates all settlement transactions. |
MasterCard RPPS Settlement Bank | The MasterCard Settlement Bank is the financial institution used by RPPS to initiate Fed wires to all Originators’ Settlement Banks and to credit all Receivers for payment files sent through the RPPS network. The MasterCard Settlement Bank sends Fed wires for the value of payments transferred through the MasterCard RPPS network to the appropriate Receivers. The MasterCard Settlement Bank is an agent of MasterCard RPPS and has an agreement with MasterCard RPPS to provide settlement services on its behalf |
How Bill Payments via RPPS Works
1 Consumer at the Originator attempts to initiate payment to the Biller User experience of the consumer is provided by the Originator, and for the purposes of this document, details of the user experience, interaction between Originator and Consumer during biller search etc. is out of scope of this document. |
2 The Originator reviews an online directory with TabaPay (Read RPPS Biller
Directory) TabaPay accesses directory at MasterCard RPPS to determine if the Biller can receive payments electronically via the RPPS network. |
3 Consumer confirms the payment to the biller. User experience of the consumer is provided by the Originator, and for the purposes of this document, details of the user experience, interaction between Originator and Consumer during biller search etc. is out of scope of this document. |
4 The Originator prepares a payment file containing bill payment transactions and sends the file to TabaPay. Validation of records is performed by TabaPay prior to sending a payment file to RPPS. |
5 TabaPay sends the file to MasterCard RPPS to process. This includes file and batch editing, account number validation and sorting/batching of payments. |
6 The MasterCard RPPS Settlement Bank initiates a Fedwire against the Originator’s
bank to retrieve funds in the amount of the payment file after all accounts number validations are complete and
inaccurate account numbers have been rejected. Note: Settlement occurs once daily at 6 PM California time for the total processing that occurred that day. |
7 The MasterCard RPPS Settlement Bank initiates Fedwires to credit the appropriate Biller’s Bank. |
8 MasterCard RPPS sends payment files to the appropriate Biller. |
MasterCard RPPS sends confirmation files to TabaPay confirming transactions received, processed, any rejects from RPPS, returns from Billers, and reasons for the reject or return. |
9 The Biller posts the credit to its account receivable. |
Considerations
Topic | Considerations |
---|---|
Returns | Billers can return any payment sent through TabaPay and the RPPS system. Any payment not posted within 24 hours by the Biller is electronically returned via the RPPS network. RPPS routes it back to the correct Originator. MasterCard RPPS also allows partial returns. These may be used for various reasons, such as discounts, commissions, rebates, or fees. The Biller can electronically return any payment to the Originator through TabaPay and RPPS network. Each returned payment includes a return code that provides the reason the payment is being returned. Payments may be returned if the Biller is unable to post the payment, as may occur if an invalid account number or closed account number is used. Errors and resulting payment disputes are minimized because MasterCard RPPS edits all transaction files prior to sending them to the Biller’s Bank. However, a Biller can return any payment to an Originator via the RPPS network/TabaPay. |
Guaranteed Funds | All funds to match payment files sent through MasterCard RPPS are transferred via Fedwire; hence, they are guaranteed funds. |
Soft Descriptor | Every Bill Payment will appear as “Bill Payment” in the consumer’s statement. Biller Search using RPPS Biller Directory |
Biller Search using RPPS Biller Directory
- Originator requests Biller Name and Biller Address from consumer and provides the values to TabaPay in a flat file. Format must be conformant with TabaPay requirements.
- TabaPay searches RPPS Biller Directory for the Biller (using numerical values from the address) and returns Biller Name to the Originator.
- Once Originator confirms the Biller Name from the Consumer, and requests account number for the Consumer at the Biller, Originator creates bill payment for the biller with TabaPay using the Consumer’s account number in the required format.
Refer RPPS Biller Directory File Format
Originator Payment File
Sample Input File
ISO |
MID |
ACH Type |
Entry Type |
Entry Description |
Amount |
IIN |
First name |
Last name |
Account type |
RTN |
Account |
Debit-Credit |
---|---|---|---|---|---|---|---|---|---|---|---|---|
6281 |
21 |
N |
RPPS |
205 |
rpps0000496 |
Samwise |
Gamgee |
RP |
123456789 |
4444444444 |
C |
|
6281 |
21 |
N |
RPPS |
443.89 |
rpps0000497 |
Samwise |
Gamgee |
RP |
123456789 |
4444444445 |
C |
|
6281 |
21 |
N |
RPPS |
5.03 |
rpps0000498 |
Samwise |
Gamgee |
RP |
233456789 |
3333333335 |
C |
|
6281 |
21 |
N |
RPPS |
6.81 |
rpps0000499 |
Samwise |
Gamgee |
RP |
123456789 |
4444444445 |
C |
|
6281 |
21 |
N |
RPPS |
155.4 |
rpps0000500 |
Samwise |
Gamgee |
RP |
*0002380203 |
*56789 |
C |
|
6281 |
21 |
N |
RPPS |
68.93 |
rpps0000501 |
Samwise |
Gamgee |
RP |
*0002380203 |
*56780 |
C |
Input File Format
Processed File from TabaPay
RPPS Files
File Details
• File sharing details will be provided to the client
- Input File name: yyyymmdd_ISO_MID_RPPSInput_N_v2-5.csv (sent to TabaPay)
- Processed file: yyyymmdd_ISO_MID_RPPSProcessed_A.csv (received from TabaPay)
o - yyyymmdd=file date
o - N=sequence number (1..n) if multiple files per cycle used
o - A=file modifier (A..Z)
o - For ISO: Do not use MID
• Comma separator for each field
Input files
• Merchant deposits input file(s) into the file sharing tool.
• All input files since last batch are processed.
• TabaPay moves Input files to 'Inboxprocessed' after processing.
• Email to [email protected] with copy to [email protected]: subject: NAME ACH; total debits and $s, total credits and $s
• Cut-off times: Same day: 7:30 AM PT; Next day: 6pm PT.
• File cutoff missed will be moved to next window
• Confirmation of processing email to merchant
• TabaPay output files, processed files, return files:
• Merchant Pickup return files, Processed files, and Output files in the 'Outbox'
Others
There following files associated with RPPS:
- Input file -> this file is generated by the merchant and contains the transaction requests.
- Processed file -> this file is generated by TabaPay. It indicates that transactions that have been sent to the bank.
- Status: Processed -> Transaction has been sent to the bank.
- Status: Rejected -> Transaction was rejected, status codes below.
TabaPay pushes RPPS files via SFTP.
SFTP Push - Security options can include:
- Merchant whitelists TabaPay IP
- SFTP ID and Password
- TabaPay public key for SFTP security (ID or ID+PW)
- File encryption using Merchant public PGP key
FAQs
FAQs | Transaction Costs
What is the cost of each bill pay transaction through Tabapay?
Standard RPPS costs + TabaPay Markup based on contract.
Will I be charged if a transaction is returned or rejected?
You will pay for every transaction that MasterCard charges; No separate TabaPay or MasterCard charges on Returns.
FAQs | Payment File Confirmation
When payments are processed, rejected, or returned how long will it take for TabaPay to inform us?
TabaPay’s cutoff is 6 PM PT, and you should receive the processed file after the nightly batch at about 6:30 PM. You will receive other reports next morning via Dropbox.
How will those payment updates be shared?
SFTP via Dropbox
FAQs | File Format
Is Account the Bill Pay Account number linking Consumer and Biller?
Yes. Account number matches against biller masks in the Mastercard RPPS Biller/Creditor Directory.
Debit/Credit designator – is this telling us that the Biller accepts Debit or Credit cards?
Credit is a payment, Debit is a reversal.
If so, where would we send the credit card number in the payment file?
Not in the payment file, but TabaPay can help you with processing consumer credit card payments through TabaPay as well. Our card acceptance suite includes PCI-Compliant iFrames as well as APIs to place transactions with us.
Does TabaPay initiate the credit card transaction to pay the biller?
Payment to the biller is handled by the network.
Biller Directory File Format
· Record 0 consists of biller information.
· Record 1 contains biller addresses.
· Record 2 contains biller masks.
o There may be multiple 1 and 2 records associated with a 0 record.
o Each 1 record may contain from 1 to 20 addresses.
o If no biller addresses are available for a biller, no 1 record will be created.
o Each 2 record may contain from 1 to 80 masks for the full and partial downloads, and from 1 to 60 masks for the advanced full download.
o There must be at least one mask for a biller.
o The address record may contain from 1 to 10 addresses, and the mask record may contain from 1 to 25 masks.
· Record 3 contains mask descriptors.
· Record 4 contains AKAs.
· Record 5 contains contacts.
· Record 6 contains phone and fax numbers.
o There may be multiple 3 records associated with a 2 record, multiple 4 and 5 records associated with a 0 record and multiple 6 records associated with a 5 record.
o Each 3 record may contain from 1 to 35 mask descriptors.
o Each 4 record may contain from 1 to 15 AKAs.
o Each 5 record may contain from 1 to 7 contacts.
o Each 6 record may contain from 1 to 20 phone numbers.
o If there is no data for record types 3 through 6, then they will not be created.
o If a mask has mask descriptors, then that mask will be on a 2 record by itself, and the descriptors will be on one or more 3 records after it.
o Likewise if a contact has phone/fax numbers the contact will be on a 5 record by itself, and the phone/fax numbers will be on one or more 6 records after it.
o Mask record may contain from 1 to 50 masks and the contact record may contain from 1 to 3 contacts.
o An 'X0' record will be generated to indicate no data for partial and advanced partial
file downloads.
· mask record may contain from 1 to 50 masks and the contact record may contain from 1 to 3 contacts.
· An 'X0' record will be generated to indicate no data for partial and advanced partial file downloads.
File Layout:
Record lengths for the fixed-width format (in bytes): Biller - 1450 to 1451; Biller Address - 232 to 4621 (2311 automated); Mask - 46 to 2701 (2251 automated); Mask Descriptor - 61 to 2101; AKA -
149 to 2221; Contact - 658 to 4600 (1972 automated); Contact Phone - 101 to 2001.
Biller Record
(0)
Field Name |
Field Size (Bytes) |
Field Description |
Record Type |
N 1 |
Type of Record; 0 - Biller |
Biller Key |
N 10 |
Unique key for this
biller record. This
value never changes. |
Record Effective Date |
N 10 |
The date of the last
change to this
record - YYYY- MM-DD |
Biller ID |
N 10 |
Unique biller ID |
Live Date |
N 10 |
The date
this biller was
first activated - YYYY-MM-
DD |
Transit Routing Number/ABA |
N 10 |
Credit Counseling Biller ID populated on the RPPS website. |
Biller Name |
AN 128 |
Corporate Name |
Biller Class |
AN 50 |
Industry Type |
Biller Type |
AN 30 |
Identifies the biller type. |
Line of Business |
AN 2 |
Indicates biller
line of business |
File Format |
N 3 |
File format for the biller |
Accepts Prenotes? |
AN 1 |
Y - Yes, N -
No |
Accepts Guaranteed Payments Only? |
AN 1 |
Y - Yes,
N - No |
*Accepts DMP Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Accepts DMP Payments Only? |
AN 1 |
Y - Yes,
N - No |
*Average Response Time (Hours) |
N 4 |
The typical
time for a biller to respond to a DMP request |
*Accept CDP Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Accept CDV Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Accept CDD Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Accept CDF Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Accept
CDN Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Accept FBD Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Accept FBC Prenotes? |
AN 1 |
Y - Yes,
N - No |
*Return CDR? |
AN 1 |
Y - Yes,
N - No |
*Return CDT? |
AN 1 |
Y - Yes,
N - No |
*Return CDA? |
AN 1 |
Y - Yes,
N - No |
*Return CDV? |
AN 1 |
Y - Yes,
N - No |
*Return CDC? |
AN 1 |
Y - Yes,
N - No |
*Return CDM? |
AN 1 |
Y - Yes,
N - No |
Require Addenda with
Reversals? |
AN 1 |
Y - Yes,
N - No |
Country Code |
AN 3 |
Three character ISO country code |
State/Province
Code |
AN 3 |
Three character ISO country subdivision code |
Check Digit Routine? |
AN 1 |
Y - Yes,
N - No |
Currency Code |
AN 3 |
Three character ISO currency code |
Territory Code |
N 1 |
1 - Global, 2 - National, 3 - Regional |
Previous Biller Name |
AN 128 |
Biller Name prior
to Change |
Note |
AN 1000 |
Comment field |
Accepts Exception Payments? |
AN 1 |
Y - Yes,
N - No |
Same Day Payment Deadline Cycle |
AN 1 |
The deadline cycle used for same-day billers. This field is not present if the biller's
concentrator or your institution(s)
does not participate in same-day processing. |
Total Addresses |
N 6 |
Total Number of Addresses
Associated with this Biller |
Total Masks |
N 6 |
Total Number of Masks Associated with this Biller |
Total AKAs |
N 6 |
Total Number of AKAs Associated with this Biller |
Total Contacts |
N 6 |
Total Number of Contacts Associated with this Biller |
*Only present in Credit
Counseling Directory
Address Record (1)
Field Name |
Field Type |
Field Description |
Record Type |
N 1 |
Type of Record; 1 - Address |
Address Key(N) |
N 10 |
Unique key for this address record.
This value never
changes. |
Record Effective Date(N) |
N 10 |
The date of the last change to this record -
YYYY- MM-DD |
Address Type(N) |
AN 40 |
The kind of address |
Address Line
1(N) |
AN 50 |
1st line of Biller
Address |
Address Line
2(N) |
AN 50 |
2nd line of Biller
Address |
City(N) |
AN 50 |
Biller City Name |
State/Province Code(N) |
AN 3 |
Three character ISO country subdivision code |
Country Code(N) |
AN 3 |
Three character ISO country code |
Postal Code(N) |
AN 15 |
Address Postal
Code |
Biller Mask Record (2)
Field Name |
Field Type |
Field Description |
Record Type |
N 1 |
Type of Record; 2 - Mask |
Mask Key(N) |
N 10 |
Unique key for this mask
record. This value
never changes. |
Record Effective Date(N) |
N 10 |
The date of the last change
to this record - YYYY- MM-DD |
Mask Length(N) |
N 2 |
Length of Mask |
Mask(N) |
AN 22 |
*=Alpha,#=Numeric,@=Alpha
or Numeric, !=Special Character |
Exception Mask?(N) |
AN 1 |
Y - Yes,
N - No |
Biller Mask Descriptor Record (3)
Field Name |
Field Type |
Field Description |
Record Type |
N 1 |
Type of Record; 3 - Biller
Mask Descriptor |
Biller Mask Descriptor Key(N) |
N 10 |
Unique key for this record.
This value never changes. |
Record Effective Date(N) |
N 10 |
The date of the last change
to this record - YYYY-MM-DD |
Mask Descriptor(N) |
AN 50 |
Description
of Biller Mask |
Biller AKA Record (4)
Field Name |
Field Type |
Field Description |
Record Type |
N 1 |
Type of Record; 4 - AKA |
AKA Key(N) |
N 10 |
Unique key for this AKA
record. This value never changes. |
Record Effective Date(N) |
N 10 |
The date of the last change
to this record - YYYY- MM-DD |
AKA Name(N) |
AN 128 |
Biller Alias |
Biller Contact Record
(5)
Field Name |
Field Type |
Field Description |
Record Type |
N 1 |
Type of Record; 5 - Contact |
Contact Key(N) |
N 10 |
Unique key for this
contact record. This value
never changes. |
Record Effective Date(N) |
N 10 |
The date of the last change
to this record - YYYY- MM-DD |
Contact Type(N) |
AN 40 |
The kind of contact |
Organization Name(N) |
AN 128 |
Organization contact is associated with |
Courtesy Title(N) |
AN 20 |
Contact courtesy title |
First Name(N) |
AN 50 |
Contact first name |
Last Name(N) |
AN 50 |
Contact last name |
Title(N) |
AN 50 |
Contact business position title |
Address Line 1(N) |
AN 50 |
1st line of Biller Address |
Address Line
2(N) |
AN 50 |
2nd line of Biller Address |
City(N) |
AN 50 |
Biller City Name |
State/Province Code(N) |
AN 3 |
Three character ISO country subdivision code |
Country Code(N) |
AN 3 |
Three character ISO country code |
Postal Code(N) |
AN 15 |
Address Postal Code |
Email(N) |
AN 128 |
Email address |
Biller Contact
Phone Record (6)
Field Name |
Field Type |
Field Description |
Record Type |
N 1 |
Type of Record;
6 - Phone |
Phone Key(N) |
N 10 |
Unique key for this
Phone record. This
value never changes. |
Record Effective Date(N) |
N 10 |
The date of the last change to this record -
YYYY- MM-DD |
Phone Type(N) |
AN 30 |
Phone, Fax or Alternate Phone |
Phone Number(N) |
AN 50 |
Can include
dashes, spaces, etc. |
File Layout for Advanced Partial
File Type:
Record lengths
for the fixed-width format(in bytes): Biller - 22 to
2072; Biller Address - 32 to 182; Mask - 32 to 126; Mask Descriptor - 42 to 192;
AKA - 32 to 338; Contact -
32 to 338; Phone - 42 to
192.
ACD Indicator |
AN 1 |
Indicates an add or delete
of a record or a change to
a field. A deleted record will have no field changes listed. |
Record Type |
N 1 |
Type of Record; 0 - Biller,
1 - Address, 2 - Mask, 3 - Mask Descriptor, 4 - AKA, 5 - Biller
Contact, 6 - Phone Number |
Biller Key |
N 10 |
All record types. Unique
left-justified key identifying either
the biller record changed (type 0) or the biller record the change
is associated with
(types 1-6). This value never changes. |
Record Key |
N 10 |
Record Types 1-6. Unique
left-justified key identifying
either the record changed (types 1,2,4 and
5) or the record the change is associated with (types 3 and 6). This
value never changes. |
Record Key |
N 10 |
Record Types 3 and 6 only.
Unique left-justified key for this record. This value never
changes. |
Effective Date |
N 10 |
The date this
change becomes effective - YYYY-MM- DD |
Field |
AN 50 |
The name of the field being
added or changed; not available on a delete. |
Current Value |
AN 1000(0), 50(1), 22(2), 50(3), 128(4), 128(5), 50(6) |
The field value as of the effective date;
available on an add
or a change. |
Prior Value |
AN 1000(0), 50(1), 22(2), 50(3), 128(4), 128(5), 50(6) |
The field value before the effective date;
available only on a change. |
No-Data Record
Field Name |
Field Size (Bytes) |
Field Description |
ACD Indicator |
AN 2 |
Indicates No Data
Modifications are available (X0) |
Effective Date |
N 10 |
Indicates the
processing date of the file
- YYYY- MM-DD |
Updated 2 months ago