BAB III PELAKSANAAN KERJA MAGANG. Kedudukan di perusahaan adalah sebagai software developer di dalam

(1)

BAB III

PELAKSANAAN KERJA MAGANG

3.1 Kedudukan dan Koordinasi

Kedudukan di perusahaan adalah sebagai software developer di dalam divisi developer yang bertanggung jawab untuk mengintegrasi Application Programming Interface (API) ke berbagai biller, vendor, dan multifinance lainnya.

Selama magang berlangsung terdapat juga berbagai tugas yang dikoordinasikan dengan senior Ainul Labib dan pak Joko selaku pimpinan software developer.

Setiap tugas yang dikerjakan harus diunduh dari Bitbucket sebagai repository versi proyek.

3.2 Tugas yang Dilakukan

Tugas yang telah dikerjakan selama magang berlangsung berupa integrasi API ke berbagai macam API lain yang berupa API multifinance, biller, maupun vendor. API PPOB pada awalnya sudah memiliki template payment gateway untuk setiap vendor, biller, dan multifinance yang menjadi mitra dimana sebelumnya sudah dikerjakan oleh senior Ainul Labib dan tim developer lainnya.

Struktur dari payment gateway bermula dari tahapan inquiry, yang bertujuan untuk menarik data Cyber Account (CA) ke aggregator IDS untuk ditransfer ke biller; payment, bertujuan untuk melakukan pembayaran dari CA ke biller dengan menggunakan data hasil inquiry sebelumnya; reversal, bertujuan untuk mengubah status pembayaran dari terbayar menjadi belum terbayar dan digunakan apabila proses pembayaran gagal ditengah jalan; advice, bertujuan untuk mengecek status suatu transaksi seperti adanya kesalahan parameter POST maupun GET di

(2)

HTTPRequest serta apabila terjadi gangguan internal pada server tujuan dan sebagainya.

Setiap tahapan transaksi dimulai dari tahap inquiry, payment, reversal, dan advice akan dimasukkan ke dalam database yang sudah dibuat sebelumnya dan data transaksi tersebut akan diperbaharui. Struktur database sudah dibuat oleh PT.

Inovasi Daya Solusi dan proses integrasi API menggunakan bahasa pemrograman Java dan menggunakan database MySQL pada tahap development dan SQL pada tahap production. Berikut adalah daftar tugas yang telah dikerjakan selama magang seperti yang ditunjukkan pada tabel realisasi magang 3.1.

Tabel 3.1 Realisasi Kerja Magang Minggu Jenis Pekerjaan yang Dilakukan

1

 Pengenalan mengenai jenis pekerjaan yang akan dilakukan.

 Mengunduh program yang diperlukan dikarenakan komputer yang digunakan adalah komputer baru.

 Membuat UI aplikasi web sesuai dengan design dan mockup yang diberikan oleh tim UI/UX.

2

 Melanjutkan aplikasi web pada minggu pertama

 Menambahkan pembayaran ke Buana dan Tunaiku pada API SolusiPay.

3

 Membaca dokumen Ultravoucher mengenai aturan koneksi API dan membuat kode untuk menghubungkan API pada aplikasi local.

 Membuat aplikasi yang mampu membuat laporan otomatis berupa excel dan PDF yang menarik data dari database.

4

 Melanjutkan aplikasi laporan otomatis dan menambahkan fitur pengiriman email kepada tim akutansi.

 Memperbaiki dan merevisi pembayaran API yang menghubungkan musilmApp dan Buana.

5  Merevisi aplikasi laporan harian.

6  Membaca dokumen, diskusi dengan klien, dan menggabungkan kode local Ultravoucher ke API PPOB.

(3)

Tabel 3.1 Realisasi Kerja Magang (lanjutan) Minggu Jenis Pekerjaan yang Dilakukan

7  Menambahkan fitur pembagian berdasarkan partner pada laporan PDF.

8  Membaca dokumen Maybank mengenai aturan koneksi API dan membuat kode untuk menghubungkan API pada aplikasi local.

9  Menambahkan fitur advice Ultravoucher pada API PPOB.

10  Membaca dokumen Fastpay mengenai aturan koneksi API.

 Membuat fitur advice untuk pembayaran TV kabel fastpay.

11

 Membuat fitur advice untuk pasca-bayar PLN fastpay.

 Melanjutkan fitur advice untuk pembayaran TV kabel fastpay dan menambahkan advice untuk asuransi dan pasca bayar pulsa.

12  Membuat kode untuk memperbaharui pasca bayar pulsa.

 Menambahkan partner PPOB, yaitu: Permata, Mizuho, Buana, BPRKPM, dan Trihamas.

13  Membuat aplikasi laporan otomatis Mandiri Tunas Finance 14  Melanjutkan aplikasi laporan otomatis MTF

3.3 Uraian Pelaksanaan Kerja Magang

Uraian magang dibagi menjadi 3 tahapan, yaitu pelaksanaan, macam kendala yang ditemukan dan solusi atas kendala.

3.3.1 Proses Pelaksanaan

Proses integrasi API dibuat dengan berbagai perangkat lunak dan perangkat keras. Spesifikasi perangkat lunak yang digunakan adalah sebagai berikut.

1. IDE Netbeans 8.2, aplikasi editor pemrograman berbahasa Java.

2. Azure Data Studio, untuk memenejemen database SQL Server.

3. BitBucket, sebagai repository proyek.

(4)

4. Xampp windows 7.3.9-0-VC15 (32 bit), untuk memenejemen database lokal,

5. OS Windows 10 (32 bit)

6. Postmanv7.8.0, untuk mengambil data API secara manual.

Perangkat keras yang digunakan untuk mengintegrasi API adalah sebagai berikut.

1. Prosesor Intel Core i7 2. RAM 4GB

3. Hard disk 1 TB

4. NVIDIA Graphic Card GeForce 820M

A. Ultravoucher

Ultravoucher merupakan sebuah aplikasi yang bertujuan untuk menyimpan berbagai voucher pembelanjaan. Voucher tersebut berupa voucher diskon yang dapat digunakan di berbagai tempat dengan cara menunjukkan voucher ke kasir. Tujuan dari integrasi API ke Ultravoucher adalah untuk melakukan transaksi pembelian voucher dari Cyber Account pengguna untuk membeli voucher tertentu.

A.1 Method

Untuk mengakses API Ultravoucher, API SolusiPay perlu token akses untuk membuat koneksi. Parameter yang diperlukan untuk mendapatkan token akses adalah app_id dan app_key yang telah dibuat untuk PT. Inovasi Daya Solusi yang berisi token yang diperlukan dengan durasi token 2 jam dan token yang

(5)

sama tidak dapat digunakan lagi setelah 2 jam token diminta sehingga dalam API PPOB menggunakan 1 token akses untuk melakukan 1 transaksi. Bila app_id dan app_key benar, maka akan muncul response pada Gambar 3.1 sebagai berikut.

Gambar 3.1 Success response get access token

Terdapat juga error response apabila app_id atau app_key tidak sesuai, maka akan muncul peringatan bahwa “appID or appKey missmatch” yang ditunjukkan pada Gambar 3.2.

Gambar 3.2 Error response get access token

Untuk mengakses API Ultravoucher diperlukan juga sebuah signature yang digunakan sebagai mekanisme autentikasi dengan setiap klien harus membuat signature untuk setiap request. Berikut adalah pola string untuk membuat signature yang ditunjukkan oleh Gambar 3.3.

Gambar 3.3 Urutan parameter signature

(6)

Setelah menggabungkan tanda tangan digital, maka selanjutnya tanda tangan digital tersebut dihash dengan menggunakan HMAC SHA-256 dengan secret key yang disamakan dengan app_key yang digunakan untuk mendapatkan token akses. Untuk mengakses API Ultravoucher melalui API SolusiPay dibutuhkan data sebagai berikut.

1. Trxid

Terdiri dari 10 string yang menandakan kode transaksi.

2. Trxdate

Berisi string bernilai tanggal transaksi dengan format yyyymmdd.

3. PartnerID

Berisi string bernilai kode partner. Contoh: IDM (Indomaret), MTF (Mandiri Tunas Finance).

4. TerminalID

String yang bernilai MAC address yang disamarkan guna untuk menjaga keamanan.

5. CustomerID

String yang bernilai ID pelanggan guna transaksi, setiap pelanggan memiliki ID pelanggan yang berbeda. Isi customerID biasa berupa nomor telepon pelanggan.

6. ExtendInfo

Array yang berisi berbagai informasi tambahan, seperti nama pelanggan, email, nomor telepon dan sebagainya,

7. TotalAmount

Berupa string yang menyimpan total biaya yang akan dibayar. Total amount

(7)

berupa gabungan dari biaya admin setiap transaksi ditambah dengan biaya yang akan dibayar. Namun tidak semua biller memiliki biaya admin, sehingga total biaya sama dengan biaya yang akan dibayar tanpa biaya admin.

8. TrackingRef

String yang bernilai nomor referensi transaksi yang digunakan untuk melacak status transaksi yang dilakukan.

9. ProductID

Berupa nilai string yang berisi produk dari Ultravoucher. Produk yang dapat dibeli terdiri dari 7 macam, yaitu:

9.1. Voucher Digital Breadlife Rp. 50.000;

Gambar 3.4 Voucher digital Breadlife 9.2. Voucher Digital Ta Wan Rp. 250.000;

9.3. Voucher Digital Ancol Entrance Gate;

(8)

9.4. Voucher Digital Ultravoucher Rp100.000;

Gambar 3.5 Voucher digital Ultravoucher 9.5. Voucher Digital Indomaret Rp 100.000;

Gambar 3.6 Voucher digital Indomaret

(9)

9.6. Voucher Digital Alfamart Rp 50.000;

Gambar 3.7 Voucher digital Alfamart 9.7. Voucher Digital Bakmi Gm Rp. 50.000.

Gambar 3.8 Voucher digital Bakmi GM

(10)

API Ultravoucher memiliki 3 metode untuk membuat pesanan. Semua metode diakses dengan menggunakan metode POST. Berikut adalah metode untuk membuat pesanan.

A.1.1 Open Order

Metode ini berguna untuk membuat sebuah pesanan baru. Berikut adalah daftar body parameter yang diperlukan untuk membuat pesanan baru yang ditunjukkan oleh tabel 3.2.

Tabel 3.2 Detail parameter open order

Order Name of Parameters Type Length Require

1 request_id String True

2 order_number String True

3 qty String True

4 sku String True

5 receiver_name String True

6 receiver_email String True

7 receiver_phone String True

Data yang digunakan untuk membuat pesanan baru adalah trackingref yang digunakan sebagai request_id sekaligus order_number, ProductID yang digunakan sebagai sku, extend info yang berisi nama pelanggan sebagai receiver_name, dan customerID sebagai receiver_phone, receiver_email berisi string spasi (“ ”) serta qty selalu 1. Berikut adalah contoh untuk mengakses metode open order API Ultravoucher dengan menggunakan aplikasi postman.

(11)

Gambar 3.9 Parameter header open order

Header berisi signature dengan pola dan hash yang telah dijelaskan sebelumnya, waktu sekarang yang ditandai dengan millisecond dan akses token yang didapatkan dengan menggunakan app_id dan app_key.

Gambar 3.10 Parameter body open order

Gambar 3.10 merupakan contoh dari body parameter untuk membuat pesanan baru dengan berurutan. Bila parameter untuk mengakses metode open order berhasil, maka metode itu akan menampilkan balasan data yang ditunjukkan oleh Gambar 3.11.

(12)

Gambar 3.11 Success response open order

Data response baru yang didapatkan dari akses metode open order adalah invoice_no yang akan digunakan untuk mengakses data order dan waktu pesanan tersebut dibuat (order_date). Parameter trackingreff yang digunakan sebagai order_number tidak boleh lebih dari 2 sehingga bila terdapat nomor pesanan yang duplikat akan menampilkan pesan error yang ditunjukkan pada Gambar 3.12.

Gambar 3.12 Error response open order

A.1.2 Data Order

Metode ini digunakan untuk melihat detail pesanan yang telah dipesan dengan metode open order sebelumnya. API Ultravoucher mampu menerima banyak pesanan voucher dalam 1 kali transaksi, namun dari API SolusiPay hanya

(13)

memperbolehkan 1 pembelian voucher dalam 1 kali transaksi. Data yang digunakan untuk mengakses metode data order beserta detailnya ditunjukkan oleh tabel 3.3.

Tabel 3.3 Detail parameter data order

Order* Name of Parameters Type Length Require

1 request_id String True

2 order_number String True

3 sku String True

4 qty String True

5 invoice_no String True

6 current_page String True

7 max_records String True

Data yang digunakan untuk melihat detail pesanan adalah trackingref yang digunakan sebagai request_id sekaligus order_number, ProductID yang digunakan sebagai sku, qty bernilai 1, invoice_no yang didapatkan dari response data open order, current_page bernilai 1 dan max_records bernilai 300 dikarenakan max_records untuk setiap transaksi Ultravoucher maksimal bernilai 300. Berikut adalah contoh untuk mengakses metode data order API Ultravoucher dengan menggunakan aplikasi postman yang ditunjukkan oleh Gambar 3.13.

.

Gambar 3.13 Parameter header data order

(14)

Header berisi signature dengan pola dan hash yang telah dijelaskan sebelumnya, waktu sekarang yang ditandai dengan millisecond dan akses token yang didapatkan dengan menggunakan app_id dan app_key.

Gambar 3.14 Parameter body data order

Gambar 3.14 merupakan contoh dari body parameter untuk melihat detail pesanan dengan parameter yang berurutan. Bila parameter untuk mengakses metode data order berhasil, maka metode itu akan menampilkan balasan data sebagai berikut yang ditunjukkan pada Gambar 3.15.

(15)

Gambar 3.15 Success response data order

Data yang didapatkan dari response metode data order berupa id_voucher, kode_voucher, tgl_expired, dan url dari voucher yang didapatkan. Url voucher pada awalnya dienkrispsi dikarenakan alasan keamanan dan harus didekripsi dengan menggunakan base64_decode. Url voucher akan menampilkan gambar voucher yang harus ditunjukkan ke kasir disaat melakukan pembelian dan harus diredeem di kasir untuk mendapatkan diskon. Berikut adalah salah satu contoh voucher Bakmi GM yang didapatkan dari url voucher yang ditunjukkan oleh Gambar 3.16.

(16)

Gambar 3.16 Voucher digital Bakmi GM

Untuk mengakses metode data order, nilai dari order_no dan qty pesanan yang diminta dengan qty yang ada, sehingga dapat memunculkan pesan error sehingga jumlah qty untuk setiap transaksi selalu bernilai 1 dan memunculkan pesan error yang ditunjukkan oleh Gambar 3.17.

Gambar 3.17 Error response data order

(17)

A.1.3 Order History

Metode ini berguna untuk mendapatkan daftar-daftar transaksi antar tanggal. Sejarah transaksi akan ditampilkan secara keseluruhan dengan interval tanggal yang sesuai dengan parameter tanggal yang dikirimkan ke API Ultravoucher.

Gambar3.18 Parameter header order history

Gambar 3.18 di atas menujukkan isi parameter header untuk mengakses metode order history. Header hanya berisi waktu sekarang yang ditandai dengan millisecond dan akses token yang didapatkan dengan menggunakan app_id dan app_key dan tidak perlu menambahkan parameter signature.

Tabel 3.4 Detail parameter order history

Name Type Length Require Description

request_id String True

start_date String Ex: 2018-12-12

10:30:12 True end_date String Ex: 2018-12-12

10:30:12 True

current_page String True

max_records String True

Max records in one page/request request is 300

Tabel 3.4 di atas menunjukkan isi serta detail dari body parameter yang dibutuhkan untuk mengakses metode order history. Body parameter berisi request_id yang bernilai bebas, start_date dan end_date dengan format yyyy-mm-

(18)

dd dan berinterval maksimal 1 bulan, current_page bernilai integer dimana nilainya lebih kecil dari total_page, dan max_records dengan nilai lebih kecil dari 300. Berikut adalah contoh body parameter untuk mengakses metode order history yang ditunjukkan oleh Gambar 3.19.

Gambar 3.19 Parameter body order history

Bila mengakses metode order history menggunakan parameter yang benar, maka metode order history akan menghasilkan response data berupa detail setiap pesanan yang terdiri dari nama distributor, tanggal pesanan, nomor pesanan, nomor invoice, email dan nomor telepon, pemesan, kode produk, nama produk, voucher sku dan nama sku, nominal voucher, harga jual, diskon distributor, harga distributor, jumlah, dan total harga jual. Riwayat transaksi yang akan ditampilkan berupa seluruh riwayat transaksi antara interval start_date dan end_date yang diisi oleh user. Semua data yang ditampilkan oleh metode ini berupa semua transaksi berdasarkan nomor pesanan yang sudah pernah dimasukkan sebelumnya. Berikut adalah contoh response data yang didapatkan dari metode order history yang ditunjukkan oleh Gambar 3.20.

(19)

Gambar 3.20 Success response order history

(20)

Metode order history mampu mengirim balasan error message bila terdapat kesalahan nilai parameter. Berikut adalah contoh error response bila parameter body tidak sesuai seperti yang ditunjukkan pada Gambar 3.21.

Gambar 3.21 Error response order history

Selain 3 metode untuk membuat pesanan seperti yang dijelaskan sebelumnya, API Ultravoucher memiliki 3 metode lain yang digunakan untuk mendapatkan master data, master data dapat berupa total balance deposit, daftar merk, dan daftar produk. Untuk mendapatkan master data dapat diakses dengan metode GET. Berikut adalah contoh metode yang digunakan untuk memperoleh master data.

A.1.4 Balance Deposit

Metode ini digunakan untuk melihat berapa banyak saldo yang dapat digunakan oleh Inovasi Daya Solusi untuk membuat pesanan voucher dan nilai balance akan berkurang sesuai total pembelian voucher yang dibeli. Berikut adalah contoh cara mengakses metode balance deposit yang ditunjukkan pada Gambar 3.22.

(21)

Gambar 3.22 Parameter header balance deposit

Header membutuhkan app_id dan app_key serta token akses yang didapatkan dari metode akses token. Metode ini tidak perlu menggunakan body parameter sehingga untuk mengakses metode balance deposit hanya memerlukan header saja. Bila berhasil mengakses metode balance deposit, maka metode ini akan mengirim response data yang menunjukkan nilai balance sekarang. Berikut adalah contoh response data yang didapatkan bila berhasil dan gagal yang ditunjukkan oleh Gambar 3.23 dan Gambar 3.24.

Gambar 3.23 Success response balance deposit

(22)

Gambar 3.24 Error response balance deposit

A.1.5 Brand List

Metode ini digunakan untuk melihat daftar keseluruhan merk atau merk tertentu. Metode ini akan menampilkan data berupa daftar kode merk, nama merk, gambar merk, dan deskripsi merk. Berikut adalah contoh mengakses metode brand list serta detail mengenai parameter GET yang ditunjukkan pada tabel 3.5.

Tabel 3.5 Detail parameter brand list

Name Type Length Require

App_id String True

App_key String True

accesstoken String True

brandcode String False

Metode brand list dapat diakses tanpa mengisi nilai parameter brandcode.

Apabila user tidak mengisi nilai brandcode, maka metode brand list akan menampilkan seluruh merk yang terdaftar pada API Ultravoucher seperti yang ditunjukkan pada Gambar 3.25.

Gambar 3.25 Parameter header brand list

(23)

Apabila berhasil mengakses metode brand list, maka metode ini akan mengirim response data yang berisi nilai kode merk, nama merk, metode pengiriman dan deskripsi dari masing-masing kode merk. response data yang dikirimkan oleh metode brand list ditunjukkan oleh Gambar 3.26.

Gambar 3.26 Parameter header brand list

Apabila user gagal mengakses metode brand list dengan parameter brand_code yang tidak terdaftar di API Ultravoucher, maka metode brand list akan mengirim error message yang menyatakan bahwa merk tidak ada atau tidak aktif. Berikut adalah contoh error response yang ditunjukkan oleh Gambar 3.27.

Gambar 3.27 Error response brand list

(24)

A.1.6 Product List

Metode ini digunakan untuk mengakses berbagai macam produk yang berupa voucher beserta deskripsi, merk, harga, harga distributor dan status produk.

Berikut adalah daftar parameter dan cara mengakses metode product list beserta detail parameter yang ditunjukkan oleh tabel 3.6.

Tabel 3.6 Detail parameter product list

Name Type Length Require

App_id String True

App_key String True

accesstoken String True

Gambar 3.28 dibawah menunjukkan contoh parameter beserta nilai parameter yang digunakan untuk mengakses metode product list. Parameter yang dibutuhkan adalah app_id, app_key, dan token akses yang didapatkan dari metode access token.

Gambar 3.28 Parameter header product list

Bila nilai parameter yang digunakan untuk mengakses metode product list sesuai, maka API Ultravoucher akan mengirim data seluruh produk yang didaftarkan oleh API Ultravoucher. Isi dari response data yang dikirimkan berupa kode merk, SKU, deskripsi SKU, nominal produk, harga distributor dan status produk. Berikut adalah contoh dari success response yang dikirimkan oleh metode product list yang ditunjukkan oleh Gambar 3.29.

(25)

Gambar 3.29 Success response product list

Bila nilai parameter tidak sesuai, maka API Ultravoucher akan mengirimkan error message yang menyatakan bahwa appID atau appKey tidak sesuai yang ditunjukkan oleh Gambar 3.30 berikut.

Gambar 3.30 Error response product list

Setelah mendapatkan balasan dari API Ultravoucher, maka daftar produk Ultravoucher disimpan dalam database pada tabel biller yang terdiri dari id ppob,

(26)

id produk, dan status produk (aktif/ tidak). Berikut adalah isi tabel biller yang ditunjukkan oleh Gambar 3.31.

Gambar 3.31 Struktur tabel biller

Id ppob digunakan sebagai id penanda produk mitra. Untuk Ultravoucher, id ppob bernilai 18, 10 untuk PDAM dan sebagainya. Id produk berisi nilai SKU yang didapatkan saat mengakses metode product list dengan total 7 SKU. Status produk dengan nama kolom isactive yang berisi nilai boolean dimana „1‟ berarti produk masih tersedia, sedangkan „0‟ berarti produk untuk sementara tidak tersedia.

Untuk deskripsi voucher disimpan pada tabel kode voucher yang terdiri dari id ppob, id produk, kode, grup id, status produk, dan deskripsi produk seperti yang ditunjukkan oleh Gambar 3.32.

Gambar 3.32 Struktur tabel kode voucher

(27)

Kolom description berisi nilai sku_name yang didapatkan dari balasan metode product list. Codeid digunakan sebagai id penanda dalam setiap groupid.

A.2 Error Code

Setiap metode terdapat bermacam error code yang berbeda maupun sama tergantung dari setiap metodenya. Berikut adalah daftar error code pada saat mengakses metode API Ultravoucher yang ditunjukkan oleh tabel 3.7.

Tabel 3.7 Daftar error code No. Kode Description

1 BAE001 Insufficient Balance

2 CLE001 appID or appKey missmatch 3 CLE002 Incomplete Request Data

4 CLN001 Client empty/ not active /id_client didn‟t match 5 CLN002 Client Not Distributor

6 ERR001 Undefined Error 7 ERR002 Can‟t connect to core 8 ERR003 Empty Error Response 9 ODA001 SKU MissMatch / Not found 10 QRY001 Query Error Gagal Insert 11 QRY002 Query Error Gagal update 12 QRY003 Query Return Null

13 QTY001 Quantity Mismatch 14 SIE001 Signature Invalid 15 SON001 Order Number Null 16 SON002 Order Number Duplicate 17 SON003 Order Number Not Found 18 SON004 SO Not Found in Stock 19 SSR001 Success Response 20 STE001 Out of Stock 21 TOE001 Token Expired 22 TOE002 Token Invalid

A.3 Proses

Untuk melakukan pembelian dari voucher oleh pelanggan. API SolusiPay memiliki 2 metode untuk melakukan pembelian dimana kedua metode menerima

(28)

parameter id transaksi, tanggal transaksi, id partner, id produk, id pelanggan, info tambahan, total biaya, tracking refference, dan id terminal.

A.3.1 Payment

Gambar 3.33 Flowchart payment method

(29)

Gambar 3.33 di atas merupakan gambar dari alur metode payment pada API SolusiPay. Pada tahap ini, API SolusiPay akan melakukan proses pembayaran dari pelanggan ke produk yang ingin dibeli dengan cara menerima semua parameter dasar dan mengecek id produk dari parameter yang diterima dengan id ppob bernilai 18 (id ppob Ultravoucher) yang sudah terdaftar di database Inovasi Daya Solusi pada tabel biller.

Apabila id produk tidak terdaftar, maka API SolusiPay akan mengeluarkan output error. Bila id produk terdaftar, maka API SolusiPay akan menjalankan metode getAccessToken yang disediakan oleh API Ultravoucher. Setelah mendapatkan token yang diperlukan untuk mengakses metode API Ultravoucher, API SolusiPay akan mengecek parameter tracking refference yang diterima karena tracking refference digunakan sebagai nomor pesanan yang diperlukan untuk membuat pesanan pada metode API Ultravoucher sehingga tracking refference tidak boleh sama sehingga tracking refference akan dicek pada tabel tb_r_Ultravoucher yang menyimpan riwayat transaksi Ultravoucher.

Pembayaran akan dibatalkan apabila nama pelanggan dan nomor telepon tidak terisi serta tracking refference yang duplikat. Nama pelanggan didapatkan dari parameter extendinfo sedangkan nomor telepon didapatkan dari parameter id pelanggan. Apabila pada parameter extendinfo tidak terdapat email pelanggan, maka email akan diisi dengan spasi (“ “).

Setelah itu API SolusiPay akan mengakses metode open order API Ultravoucher untuk mendapatkan invoice number dan order number (Ultravoucher). Selanjutnya API SolusiPay akan mengakses metode data order API Ultravoucher untuk melihat detail dari pesanan yang sudah dibuat

(30)

sebelumnya dengan menggunakan invoice number yang didapatkan dari metode open order. Setelah mendapatkan balasan dari metode open order dan data order, data-data yang didapatkan dari kedua metode sebelumnya akan disimpan pada tabel tb_r_Ultravoucher. Pada tabel ini, terisi informasi mengenai riwayat transaksi yang berhubungan dengan Ultravoucher yang terdiri dari tracking refference, id produk, invoice number, email pelanggan, nomor telepon pelanggan (id pelanggan), nama pelanggan, tanggal transaksi, id voucher, kode voucher, tanggal kadaluarsa voucher, link url voucher, dan total biaya yang dibayarkan.

Apabila metode payment berhasil, maka metode payment API SolusiPay akan mengirim balasan success response yang terdiri dari ID transaksi, tanggal transaksi, ID mitra, ID produk, ID pelanggan, extend info, total biaya, nomor struk, tracking refference, ID terminal, signature dan berbagai data tambahan. Data tambahan yang dimaksud adalah struk pembelanjaan yang berisi data berupa tanggal lunas, kode voucher, deskripsi voucher, tanggal kadaluarsa, nomor struk, tautan voucher, total tagihan, dan total bayar pelanggan. Isi dari struk tersebut dapat diilustrasikan seperti pada Gambar 3.34 di bawah berikut.

Gambar 3.34 Additional data builder payment

(31)

A.3.2 Advice

Gambar 3.35 Flowchart advice method

Pada tahap ini, API SolusiPay akan mengecek status pembayaran suatu transaksi dengan cara menerima semua parameter dasar dan mengecek id produk dari parameter yang diterima dengan id ppob bernilai 18 (ID ppob Ultravoucher)

(32)

yang sudah terdaftar di database Inovasi Daya Solusi pada tabel biller. Apabila id produk tidak terdaftar, maka API SolusiPay akan mengeluarkan output error.

Bila id produk terdaftar, maka API SolusiPay akan mengambil berbagai data seperti trackingreff, productid, invoice, receiver_email, receiver_name, trxdate, id_voucher, kode_voucher, exipreddate, url voucher, dan total biaya dari tabel tb_r_Ultravoucher berdasarkan ID pelanggan dan tracking refference yang diambil dari parameter POST metode advice SolusiPay.

Apabila data transaksi berdasarkan ID pelanggan dan tracking refference tidak ditemukan, maka API SolusiPay akan mengeluarkan response error yang menyatakan bahwa transaksi tidak ditemukan. Bila terdaftar, maka API SolusiPay akan mengecek transaksi yang berhasil sesuai dengan product id dan tracking refference yang didapatkan dari metode POST API SolusiPay untuk mengambil nilai kode voucher, ID voucher, tanggal kadaluarsa, struk, url voucher, dan deskrpsi voucher. Apabila kode voucher kosong, maka API SolusiPay akan menampilkan error message yang menyatakan bahwa transaksi tidak ditemukan.

Apabila metode advice berhasil, maka metode payment API SolusiPay akan mengirim balasan success response yang terdiri dari ID transaksi, tanggal transaksi, ID mitra, ID produk, ID pelanggan, extend info, total biaya, nomor struk, tracking refference, ID terminal, signature dan berbagai data tambahan. Data tambahan yang dimaksud adalah struk pembelanjaan yang berisi data berupa tanggal lunas, kode voucher, deskripsi voucher, tanggal kadaluarsa, nomor struk, tautan voucher, total tagihan, dan total bayar pelanggan. Isi dari struk tersebut dapat diilustrasikan seperti pada Gambar 3.36 di bawah berikut.

(33)

Gambar 3.36 Additional data builder advice

B. Maybank

PT Bank Maybank merupakan salah satu bank swasta di Indonesia yang termasuk bagian dari grup Malayan Banking Berhad (Maybank), salah satu grup penyedia layanan keuangan terbesar di ASEAN. Maybank Indonesia menyediakan serangkaian produk dan jasa komprehensif bagi nasabah individu maupun korporasi melalui layanan Community Financial Services (Perbankan Ritel dan Perbankan Non-Ritel) dan Perbankan Global, serta pembiayaan otomotif melalui entitas anak yaitu WOM Finance untuk kendaraan roda dua dan Maybank Finance untuk kendaraan roda empat juga pembayaran lain seperti BPJS atau PDAM.

(34)

B.1. Data

API Maybank memiliki 22 jenis data dengan atribut dan format yang berbeda. Setiap data tidak selalu digunakan pada setiap metode dan berikut adalah penjelasan untuk setiap data beserta atribut dan formatnya.

B.1.1 MTI

MTI merupakan singkatan dari Message Type Identifier. MTI terdiri dari 4 digit yang digunakan sebagai kode yang menandakan jenis pesan digunakan untuk mengakses metode API Maybank dan harus digunakan pada setiap metode.

Berikut adalah jenis kode MTI beserta penjelasannya pada tabel 3.8.

Tabel 3.8 Daftar MTI Code Description

0200 Inquiry/Payment Request 0210 Inquiry/Payment Response 0400 Reversal Request

0410 Reversal Response

B.1.2 Processing Code

Processing code digunakan untuk menentukan tipe transaksi pelanggan dan harus dicantumkan pada seluruh metode API Maybank. Terdiri dari 6 digit yang memiliki format dengan 2 digit pertama digunakan untuk mengidentifikasi tipe transaksi pelanggan serta metode yang akan diproses, digit ke 3 dan 4 digunakan untuk menentukan tipe akun yang akan digunakan untuk melakukan transaksi. Detail dari processing code dapat dilihat pada tabel 3.9.

(35)

Tabel 3.9 Daftar Processing Code Digit Code Description

1-2

38 Bill Inquiry

37 Transfer Info Inquiry 18 Payment Settle 47 Transfer Settle

3-4 10 From Saving Account 20 From Checking Account 5-6 00 Always Zero

B.1.3 Transaction Amount

Transaction amount digunakan sebagai total pembayaran yang akan dibayar. Semua metode API Maybank harus selalu mencantumkan data ini dan pada response API Maybank juga akan mengembalikan nilai yang sama. Terdiri dari 14 digit integer dimana 2 angka terakhir akan dijadikan 2 desimal di belakang tanda koma. Contoh transaksi 100 juta akan menjadi 10000000000.

B.1.4 Transmission Date

Transmission date digunakan untuk menandakan waktu transaksi yang akan dijalankan dalam GMT. Terdiri dari 10 karakter dengan format MMDDhhmmss (bulan tanggal jam menit detik).

B.1.5 Terminal Trace Number

Terminal Trace Number merupakan sebuah data unik yang digunakan untuk mengidentifikasi sebuah transaksi. Dalam satu transaksi yang menjalankan fungsi inquiry, payment, dan reversal akan memilik terminal trace number yang sama. Terminal trace number terdiri dari 6 digit numerik.

(36)

B.1.6 Local Time Transaction

Local time transaction terdiri dari 6 digit numerik yang menunjukkan waktu transaksi yang terjadi dalam zona waktu lokal dengan format hhmmss (jam menit detik).

B.1.7 Local Date Transaction

Local Date Transaction terdiri dari 4 digit numerik yang menunjukkan tanggal transaksi yang sedang terjadi dalam zona waktu lokal dengan format MMDD (bulan hari).

B.1.8 POS Entry Mode Code

Kode ini bertujuan untuk menentukan tipe pengambilan data pelanggan yang terdiri dari 3 digit numerik dan selalu bernilai „021‟. Berikut adalah penjelasan mengenai POS Entry Mode Code.

Tabel 3.10 Daftar POS Entry Mode Code Code Description

1 PIN entry capability 2 PAN/date entry mode

B.1.9 Acquiring Institution Identification Code

Kode ini merupakan kode mitra yang akan disediakan oleh pihak Maybank dan digunakan untuk mengidentifikasi mitra yang diajak untuk bekerja sama.

Setiap mitra memiliki kode mitra yang berbeda dan harus dicantumkan untuk mengakses semua metode API Maybank.

(37)

B.1.10 Retrieval Reference Number

Merupakan nomor yang digunakan dengan elemen data lainnya sebagai kunci untuk mengidentifikasi dan menelusuri semua pesan yang berkaitan kepada pelanggan yang melakukan transaksi. Terdiri dari 12 digit numerik.

B.1.11 Host Response Code

Merupakan kode 2 digit numerik yang digunakan untuk menandakan pesan bagi pengguna akses API Maybank. Berikut adalah tabel 3.11 yang berisi contoh response code yang dapat diberikan oleh API Maybank.

Tabel 3.11 Daftar response code Maybank Code Description

00 Approve or completed successfully 01 Refer to Card Issuer

03 Invalid Merchant 04 Pick up card

05 Default – Do not honor 06 Do not honor

07 Pick up card – Special condition 08 Honor with identification

09 Request in progress 12 Cannot reverse transaction

13 Transaction amount is differ with total bill amount

B.1.12 Card Acceptor Terminal Identification

Merupakan elemen data yang digunakan untuk mengakomodasi kode unik pada transaksi terminal. Data ini harus dicantumkan kepada seluruh transaksi pembayaran dan terdiri dari ID terminal. Terdiri dari 8 digit yang diawali dengan 0 dari depan.

(38)

B.1.13 Card Acceptor Identification

Merupakan elemen data yang terdiri dari kode institusi/kantor yang diletakkan pada mesin transaksi Maybank. Setiap layanan pembayaran institusi memiliki kode ID yang berbeda. Terdiri dari 15 digit yang diawali dengan digit 0 dari depan.

B.1.14 Card Acceptor Name/Location

Terdiri dari nama dan lokasi terminal. Data ini harus dicantumkan ke dalam setiap transaksi dengan kode MTI 0200 dan 0400.

B.1.15 Additional Data

Merupakan data yang digunakan untuk menampilkan data pembayaran.

Data ini akan ditampilkan pada request message suatu transaksi apabila transaksi mengembalikan response code “00”.

Tabel 3.12 Daftar kode additional data Code Description

1 Inquiry request 2 Inquiry response

3 Payment/transfer request 4 Payment/transfer response

B.1.16 Currency Code

Kode yang digunakan untuk mengidentifikasi mata uang dari data transaction amount. Dalam kasus ini currency code bernilai “360” yang bernilai IDR.

(39)

B.1.17 Information Data

Merupakan kode yang berisi response data dari metode inquiry dan payment yang akan ditampilkan pada layar / struk.

B.1.18 Transaction Currency Code

Sama seperti currency code pada bagian B.1.16 namun lebih dikhususkan untuk transaksi dengan standard ISO. Data ini harus diisi pada seluruh metode transaksi.

B.1.19 Original Data Element

Merupakan elemen data yang didefinisikan pada metode reversal yang terdiri dari data dari request awal dan ditujukan untuk mengidentifikasi pesan yang sedang diproses ulang. Terdiri dari 42 digit yang didefinisikan oleh tabel 3.13 di bawah berikut.

Tabel 3.13 Daftar digit Original Data Element Digit Description

1-4 original message type identifie 5-10 original trace no

11-20 original date & time GMT

21-31 original acquiring institution code 31-42 original forwarding institution code

B.1.20 Payee

Merupakan tujuan pembayaran. Data ini harus dicantumkan dalam semua metode bill payment dan purchase. Berisi nilai nomor tagihan yang akan dibayarkan dan terdiri dari 20 digit.

(40)

B.1.21 From Account

Merupakan sumber akun yang melakukan pembayaran dan harus dicantumkan ke dalam setiap metode pembayaran. Terdiri dari 13 digit dengan ketentuan seperti pada tabel 3.14.

Tabel 3.14 Digit from account Digit Description

1-3 Currency Code ( IDR = 360 ) 4-10 Account Number

B.1.22 To Account

Merupakan akun tujuan pembayaran dan harus dicantumkan pada setiap metode transaksi pembayaran dan berisi nomor akun dengan total 20 nomor digit.

B.2 Method

Untuk mengakses API Maybank, API SolusiPay perlu token akses untuk membuat koneksi dengan metode lainnya. Untuk mendapatkan token akses API SolusiPay perlu mengakses metode AccessToken dengan menggunakan parameter ID client dan secret key client dengan nilai grant type “client_credentials”.

Metode diakses dengan menggunakan metode POST dan perlu menggunakan default trust manager. Apabila API Maybank langsung diakses tanpa menggunakan default trust manager, maka akan mengeluarkan pesan error pada sertifikat SSL handshake. Metode ini akan mengirim success response yang berupa nilai akses token, tipe token, dan waktu kadaluarsa token dalam satuan detik seperti pada Gambar 3.37 dibawah ini.

(41)

Gambar 3.37 Success response getAccessToken

API Maybank memiliki 3 metode yang terdiri dari proses inquiry, payment, dan reversal. inquiry, Proses inquiry bertujuan untuk menarik data Cyber Account (CA) ke aggregator IDS untuk ditransfer ke biller; payment, bertujuan untuk melakukan pembayaran dari CA ke biller dengan menggunakan data hasil inquiry sebelumnya; reversal, bertujuan untuk mengubah status pembayaran dari terbayar menjadi belum terbayar dan digunakan apabila proses pembayaran gagal ditengah jalan; advice, bertujuan untuk mengecek status suatu transaksi seperti adanya kesalahan parameter POST maupun di HTTPRequest serta apabila terjadi gangguan internal pada server tujuan dan sebagainya. Tipe pengiriman data menggunakan metode POST dan menggunakan tipe pengiriman dalam bentuk raw data.

Setiap metode header API Maybank memiliki nilai parameter yang sama dengan metode lainnya. Berikut adalah tabel 3.15 yang berisi daftar parameter header dan detailnya.

Tabel 3.15 Detail parameter header

Field Name Format Description

messageID Ans-32 UUID Unique Number

channelID An-10 Identification Channel Code (MBS for Mitra Bisnis/Payment Point and MRMT for Mitra Remittance)

(42)

Tabel 3.15 Detail parameter header (lanjutan)

Field Name Format Description

reference Ans-20 Mitra/Channel Reference Number transdatetime dd-MM-yyyy hh:mm:ss Message Transamission Date Time

B.2.1 Inquiry

Proses inquiry memiliki 2 macam metode akses, yaitu billinquiry dan transferInquiryInfo. Kedua metode ini bertujuan untuk menghubungkan cyber account pelanggan ke Maybank untuk melakukan permohonan pembayaran.

Berikut adalah contoh ketentuan dari metode billinquiry dan transferInquiryInfo yang dijelaskan pada tabel 3.16 dan tabel 3.17.

Tabel 3.16 Detail parameter billinquiry

Field Name & Description Request Response

MTI Message Type Identifier 0200 0210

DE003 Processing Code M M

DE004 Transaction Amount M M

DE007 Transmission Date and Time GMT M M

DE011 System Trace Audit Number M M

DE012 Local Time, Transaction M M

DE013 Local Date, Transaction M M

DE022 POS Entry Mode Code M M

DE032 Acquiring Institution Identification Code M M

DE037 Retrieval Reference Number M M

DE039 Response Code - M

DE041 Card Acceptor Terminal ID M M

DE042 Card Acceptor Identification C C

DE043 Card Acceptor Name/Location C C

DE048 Additional Data – Private M M

DE049 Transaction Currency Code M M

DE062 Additional Data - C

DE098 Payee M M

DE102 From Account M M

(43)

Tabel 3.17 Detail parameter transferInquiryInfo

DE103 To Account M M

Untuk parameter body metode inquiry, pada nilai parameter MTI harus selalu bernilai “200” yang menandakan bahwa proses yang akan dilaksanakan adalah proses inquiry. Untuk 2 digit processing code bernilai “38” untuk proses bill inquiry atau “37” untuk proses transfer info inquiry, untuk digit ke-3 dan ke-4 bernilai “10” untuk menandakan bahwa akun yang digunakan berasal dari saving account atau “20” untuk menandakan bahwa akun yang digunakan berasal dari checking account, untuk digit ke-5 dan ke-6 selalu bernilai “0”. Berikut adalah contoh parameter untuk mengakses metode inquiry.

(44)

Gambar 3.38 Parameter akses inquiry

Apabila transaksi berhasil, maka metode inquiry akan mengembalikan data response dengan tambahan data pada variabel addData untuk menampilkan informasi Cyber Account yang akan melakukan pembayaran. Berikut adalah contoh response dari metode inquiry pada Gambar 3.39.

(45)

Gambar 3.39 Response message inquiry

B.2.2 Payment

Proses payment memiliki 2 macam metode akses, yaitu billPaymentAndPurchase dan transferSettle. Kedua metode ini bertujuan untuk melakukan proses pembayaran berdasarkan data dari cyber account pelanggan yang diajukan melalui proses inquiry ke API Maybank untuk melakukan melakukan proses pembayaran ke biller. Berikut adalah contoh ketentuan dari metode billPaymentAndPurchase dan transferSettle yang dijelaskan pada tabel 3.18 dan tabel 3.19.

(46)

Tabel 3.18 Detail parameter billPaymentAndPurchase

DE098 Payee M M

Tabel 3.19 Detail parameter transferSettle

DE103 To Account M M

(47)

Untuk parameter body metode payment, pada nilai parameter MTI harus selalu bernilai “200” yang menandakan bahwa proses yang akan dilaksanakan adalah proses payment. Untuk 2 digit processing code bernilai “17” untuk proses payment/settle atau “47” untuk proses transfer settle, untuk digit ke-3 dan ke-4 bernilai “10” untuk menandakan bahwa akun yang digunakan berasal dari saving account atau “20” untuk menandakan bahwa akun yang digunakan berasal dari checking account, untuk digit ke-5 dan ke-6 selalu bernilai “0”. Berikut adalah contoh parameter untuk mengakses metode payment.

Gambar 3.40 Body message payment

(48)

Apabila transaksi berhasil, maka metode payment akan mengembalikan data response untuk menyatakan bahwa pembayaran berhasil dilakukan. Berikut adalah contoh response dari metode payment pada Gambar 3.41.

Gambar 3.41 Response message payment

B.2.3 Reversal and Advice

Proses reversal and advice hanya memiliki 1 macam metode akses, yaitu reversalAndAdvice. Metode ini bertujuan untuk melakukan proses pengulangan transaksi apabila gagal melakukan pembayaran dan melakukan pengecekan setiap transaksi berdasarkan data dari cyber account pelanggan yang diajukan melalui proses reversal ke API Maybank untuk melakukan melakukan proses pembayaran ke biller. Berikut adalah contoh ketentuan dari metode reversalAndAdvice dan transferSettle yang dijelaskan pada tabel 3.20.

(49)

Tabel 3.20 Detail parameter reversalAndAdvice

DE090 Original Data Elements M M

DE098 Payee C C

DE103 To Account C C

Untuk parameter body metode reversal and advice, pada nilai parameter MTI harus selalu bernilai “400” yang. Berikut adalah contoh parameter untuk mengakses metode payment seperti yang ditunjukkan pada Gambar 3.42.

(50)

Gambar 3.42 Body message reversal

(51)

3.3.2 Kendala yang Ditemukan

Berikut adalah beberapa kendala yang dialami selama proses pengerjaan magang.

a. Mengintegrasi API dengan menggunakan software Netbeans yang belum pernah digunakan sebelumnya.

b. Penggunaan software manajemen proyek bitbucket yang belum pernah digunakan sebelumnya.

c. Kekurangpahaman akan proses integrasi API dengan mitra

3.3.3 Solusi atas Kendala yang Ditemukan

Berikut adalah beberapa solusi atas kendala yang dialami.

a. Mempelajari software Netbeans melalui video tutorial di youtube, membaca dokumentasi, dan meminta referensi dari senior dan rekan kerja.

b. Mencoba untuk membiasakan diri dengan UI bitbucket dan membuat proyek / repository untuk dites.

c. Meminta kepada senior untuk bergabung ke grup mitra Whatsapp.